Re: [Pharo-dev] ApplicationSecurity Questions
I forgot one: 3. It was not clear to me how to get libsodium.dylib, which was not installed on my Mac. There were some old ML posts about an automatic binary download mechanism using Dropbox, but the link seemed dead. I ended up downloading and manually copying into the Pharo VM Plugins folder per [1], but was a little uneasy about that. It would be good to add "the right way" to the readme! 1. https://eighty-twenty.org/files/libsodium/libsodium.dylib.gz - Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
[Pharo-dev] ApplicationSecurity Questions
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
[Pharo-dev] Cryptic Mac Error: Pharo "is damaged and can't be opened"
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-downloaded-from-anywhere-in-macos-sierra - Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Re: [Pharo-dev] Iceberg "Duplicated project!"
hi, > On 4 Jun 2018, at 19:11, Martin McClure 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 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 >>> >> >
Re: [Pharo-dev] Iceberg "Duplicated project!"
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 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 >> >
Re: [Pharo-dev] Iceberg "Duplicated project!"
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 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 >
[Pharo-dev] [Pharo 7.0-dev] Build #1005: 22047 Categorize System-Sources
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%20and%20branch%20Pipeline/job/development/1005/
[Pharo-dev] [Pharo 7.0-dev] Build #1004: Revert "14063-clean-up-definitionForNautilus"
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%20and%20branch%20Pipeline/job/development/1004/
[Pharo-dev] Esteban's ChangeLog week of 28 May 2018
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=3/6/2018 ChangeLog = 1 June 2018: *I just added support for stateful traits in [tonel](>https://github.com/pharo-vcs/tonel/commit/7147d7b21ef614b958aaed1f4844c86da537d049) 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/iceberg/pull/829) *I backported stable P7 VM to P6.1. This should fix some problems... and create some new, as always :) cheers! Esteban
