June 2018 - Pharo-dev - lists.pharo.org

ApplicationSecurity Questions

by Sean P. DeNigris

I'm very excited about this library. I always wished for an off the shelf web app security solution! Not sure if this is the right ML, but since the library was announced hereâ¦ 1. I read that the project was ported to GH. While there is a baseline there, there is also a configuration on GH, but (the weird part) - it still points to StHub instead of loading the baseline from GH 2. How does one actually use the library in practice e.g. for a web app with protected content? The 3 blog posts cover adding a user, but I don't understand how to tie AS in with say Seaside. Is there an example project using it or some docs on that? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 5, 2018

Cryptic Mac Error: Pharo "is damaged and can't be opened"

by Sean P. DeNigris

This is the "helpful" message one now gets when trying to install an unsigned app on a Mac. Here are two workarounds*: 1. Re-enable Gatekeeper "Install from Anywhere" option via `sudo spctl --master-disable` 2. Unquarantine Pharo only via `sudo xattr -r -d com.apple.quarantine /Applications/Pharo.app` * https://apple.stackexchange.com/questions/243687/allow-applications-downloa… ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 4, 2018

Re: [Pharo-dev] Iceberg "Duplicated project!"

by Esteban Lorenzano

hi, > On 4 Jun 2018, at 19:11, Martin McClure <martin(a)hand2mouse.com> wrote: > > On 06/04/2018 05:34 AM, Esteban Lorenzano wrote: >> hello Martin, >> >> This is becacuse metacello finds another version already registered. > How is it already registered? This is a fresh image. The only thing that > has happened is that it is already cloned, since I had loaded it in a > different image. Deleting the cloned repository makes it work, but fails > again on the next clean image until I delete the repository again. > This does not seem correct. It was working correctly a week earlier > (which is, I think, two Iceberg versions ago?) it was not working properly. what happened before is that iceberg was silently taking the version already present. this may be the preferred behaviour but in other contexts is plain wrong, hence the need to force you to choose. this is why we introduced the #onUpgrade: protocol. btw, even if is not an âupgradeâ, iceberg will fail to detect a reference to (for example) tag v1.0.0 is the same as a commit SHA (we are working on this, but it will not be anytime soon). So, I guess you need to go for the #onUpgrade: mechanism. cheers, Esteban > > Regards, > -Martin > >> On 2 Jun 2018, at 04:42, Martin McClure <martin(a)hand2mouse.com> wrote: >>> On a Pharo7, Linux, from yesterday: >>> Build information: >>> Pharo-7.0+alpha.build.994.sha.6b52ae62b755d8778fa0b5a4ac53b39b6c107dc9 >>> (32 Bit) >>> >>> During an Iceberg load of a Metacello baseline, I get a dialog >>> >>> Duplicated project! >>> There is already a project "OSSubprocess" in this installation. >>> >>> It's true that I do have a Git clone of OSSubprocess in my >>> pharo-local/iceberg directory, since this is the second image I've >>> loaded into, but before it's always just used the already-cloned repo >>> rather than trying to create a new one. >>> >>> Any ideas on what the correct behavior currently is (for the system, and >>> for me) at this point? >>> >>> Thanks, >>> -Martin >>> >> >

June 4, 2018

Re: [Pharo-dev] Iceberg "Duplicated project!"

by Martin McClure

On 06/04/2018 05:34 AM, Esteban Lorenzano wrote: > hello Martin, > > This is becacuse metacello finds another version already registered. How is it already registered? This is a fresh image. The only thing that has happened is that it is already cloned, since I had loaded it in a different image. Deleting the cloned repository makes it work, but fails again on the next clean image until I delete the repository again. Â This does not seem correct. It was working correctly a week earlier (which is, I think, two Iceberg versions ago?) Regards, -Martin > On 2 Jun 2018, at 04:42, Martin McClure <martin(a)hand2mouse.com> wrote: >> On a Pharo7, Linux, from yesterday: >> Build information: >> Pharo-7.0+alpha.build.994.sha.6b52ae62b755d8778fa0b5a4ac53b39b6c107dc9 >> (32 Bit) >> >> During an Iceberg load of a Metacello baseline, I get a dialog >> >> Duplicated project! >> There is already a project "OSSubprocess" in this installation. >> >> It's true that I do have a Git clone of OSSubprocess in my >> pharo-local/iceberg directory, since this is the second image I've >> loaded into, but before it's always just used the already-cloned repo >> rather than trying to create a new one. >> >> Any ideas on what the correct behavior currently is (for the system, and >> for me) at this point? >> >> Thanks, >> -Martin >> >

June 4, 2018

Re: [Pharo-dev] Iceberg "Duplicated project!"

by Esteban Lorenzano

hello Martin, This is becacuse metacello finds another version already registered. Usually you can avoid that adding: onConflict: [ :e | e useLoaded ] and/or onUpgrade: [ :e | e useLoaded ] both messages act in different contexts: onConflict: between what is in disk and what is in image. onUpgrade: between what is in your local repo and what is asked to be cloned. and take note that many baselines may have cyclic references (that metacello solves, at the end), this is not because you *actually* have already the project loaded/cloned. cheers, Esteban > On 2 Jun 2018, at 04:42, Martin McClure <martin(a)hand2mouse.com> wrote: > > On a Pharo7, Linux, from yesterday: > Build information: > Pharo-7.0+alpha.build.994.sha.6b52ae62b755d8778fa0b5a4ac53b39b6c107dc9 > (32 Bit) > > During an Iceberg load of a Metacello baseline, I get a dialog > > Duplicated project! > There is already a project "OSSubprocess" in this installation. > > It's true that I do have a Git clone of OSSubprocess in my > pharo-local/iceberg directory, since this is the second image I've > loaded into, but before it's always just used the already-cloned repo > rather than trying to create a new one. > > Any ideas on what the correct behavior currently is (for the system, and > for me) at this point? > > Thanks, > -Martin >

June 4, 2018

[Pharo 7.0-dev] Build #1005: 22047 Categorize System-Sources

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1005 was: FAILURE. The Pull Request #1475 was integrated: "22047 Categorize System-Sources" Pull request url: https://github.com/pharo-project/pharo/pull/1475 Issue Url: https://pharo.fogbugz.com/f/cases/22047 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 4, 2018

[Pharo 7.0-dev] Build #1004: Revert "14063-clean-up-definitionForNautilus"

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1004 was: SUCCESS. The Pull Request #1476 was integrated: "Revert "14063-clean-up-definitionForNautilus"" Pull request url: https://github.com/pharo-project/pharo/pull/1476 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 4, 2018

Esteban's ChangeLog week of 28 May 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 28 May 2018 to 3 June 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=28/5/2018&to=3/6/2018 ChangeLog ========= 1 June 2018: ------------ * I just added support for stateful traits in [tonel](>https://github.com/pharo-vcs/tonel/commit/7147d7b21ef614b958aaed1f4844c86da…) It was pretty simple :) 30 May 2018: ------------ * I spent sometime on the UI of Iceberg. This time I improved the version history browser (you know, the browser that appears on Calypso, whenever you have a repository connected to your sources). In fact, I changed the old implementation (based on Glamour) to our own implementation. This allow us to share some functionality from history browser (like the ability to checkout from a version), and I also added the ability of install a particular version. this is the PR [https://github.com/pharo-vcs/iceberg/pull/829](https://github.com/pharo-vcs… * I backported stable P7 VM to P6.1. This should fix some problems... and create some new, as always :) cheers! Esteban

June 4, 2018

Re: [Pharo-dev] [PROPOSAL] Put the WorldMenu in a Menu bar

by Denis Kudriashov

There is booklet https://github.com/SquareBracketAssociates/ Booklet-Infrastructure (Commander chapter). 2018-06-03 16:23 GMT+03:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Commands are responsible to build menu items for themselves. By default >> they build single item. But you can override method and generate multiple >> items. >> Look for example at ClySwitchQueryScopeCommand>>#fillContextMenu:using: >> > > It would be nice to have a complete 1:1 example to a more-complex world > menu. > I see the value of using Commander, but it is (imho) order of magnitude > more complex. > > E.g., for a trivial method that creates a parent and a child entry > > (aBuilder item: #Parent) > icon: #plus asIcon; > label: 'Parent'; > parent: #MostUsedTools; > keyText: 'o, p'; > action: [ self doParentStuff ]. > It looks simpler, yes. But it is completely unreusable. As soon as you will need to access #doParentStuff from places other than standard menu you will duplicate many parts of command (name, icon, shortcut, general initialization of parameters). We already duplicate shortcut information in menu and shortcut builders. Notice #keyText:. I don't think that Commander approach is more difficult than builder. For the first command in application it is almost same. And I would say that adding new menu to application using Commander is much simpler and straightforward task. (aBuilder item: #Child) > parent: #Parent; > label: 'Child'; > icon: #minus asIcon; > keyText: 'o, c'; > action: [ self doChildStuff ]. > > * I would need two classes, one for each command > * For each line of the builder a I need a separate method (shortcut, name, > icon, ...) > * I need another class to represent the "parent" context (similar to > CmdWorldMenuContext) > Look at booklet. In common cases you will not need to use context classes in activation methods. This one can be implemented using World: CmdShortcutCommandActivation by: $s meta for: World But I wanted to not put morphic dependency into such global commands.. * I need to know to know how Commander work to even know what I am doing -- > with the current setup it is obvious and people can just copy paste and be > done. > > I don't really think that it can be any simpler than is the current state, > so any change would inevitably increase complexity. And with commander it > feels like a lot of incidental complexity here. > > Would it be possible to somehow generate commands on the fly? Some sort of > "CmdPluggableCommand" that would be populated based on the current builder? > I don't see the value for this because it will not bring reusable commands. At least I do not see how it could be possible. > > Peter >

June 3, 2018

Calypso debugging across #wait with multithreaded tests

by Ben Coman

Before I log an issue... in Pharo 7 using Calypso to run a test by clicking its status-dot, when trying to step <Over> a semaphore #wait the UI locks up. I presumed this was due to the #wait effectively occurring in the main UI thread, so I solved this by forking the test as follows. Is that a reasonable thing to do? ClyRunTestsFromMethodsCommand >> runTest: testSelector of: testClass [ | testResult | testResult := testClass debug: testSelector. self notifyUserAboutResults: testResult with: 'Method: ' , testClass asString , '>>#' , testSelector asString ] forkNamed: 'TESTING ' , testClass asString , '>>#' , testSelector asString With that change, you can step over a #wait as if it wasn't there, which IIRC is in line with the old behaviour. Now a bit of a dream, but even better would be that just the debugger stepping over the #wait was suspended (rather than the whole UI) with an indication like a red border. When the #wait was signaled, the red border would disappear and the debugger might jump to the top. cheers -ben

June 3, 2018