Sorabito friends just released another great binding for Pharo.
https://github.com/newapplesho/salesforce-smalltalk
Thank you.
Stef
-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
Sorabito friends just released another great binding for Pharo.
https://github.com/newapplesho/salesforce-smalltalk
Thank you.
Stef
Hi guys
Hi all,
I’ve put up the _beginnings_ of a wrapper for OpenSSL on STH:
Metacello new
baseline: ‘OpenSSL’;
smalltalkhubUser: ‘PierceNg’ project: ‘OpenSSL-Pharo’;
load.
Verified on Pharo 6 32- and 64-bit.
My near term goal is to wrap enough libcrypto functionality to implement the
client-side of Let’s Encrypt.
I meant to put it up on GH, for the ease of forking and PRs, but I couldn’t get
Iceberg to work, and gitfiletree also failed to load, so STH it is. ¯\_(ツ)_/¯
Collaboration welcome.
PierceNg
Hi,
Hi,
I backported lastest Iceberg version to Pharo 6.1 to allow people to benefit for latest changes.
This version has an important amount of tweak and fixes, but most important is the inclusion of tonel file format (this is default for Pharo 7.0, optional for Pharo 6.1) and introduces a file-per-class format.
The advantages of this format has everything to do with the speed of access (is easier to reconstruct a package like) and the space on disk (methods are usually small but minimum space in disk is usually 4k so we waste a lot of space). Is also a better format for SSD disks.
To backport Iceberg 0.6.2 I also needed to backport latest version of Metacello, so Pharo 6.1 and Pharo7+ users now also have the latest version of it available 🙂
cheers!
Esteban
And here is how to do it in Pharo:
signature := ‘https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/lastSuccessfulBuild/artifact/Pharo6.1-mac.zip.sha256.txt‘ asUrl retrieveContents findTokens: Character separators.
hash := signature first.
signedFile := signature second.
url := ‘http://files.pharo.org/platform/Pharo6.1-mac.zip‘ asUrl.
ZnClient new url: url; downloadTo: FileLocator temp. “somewhat slow”
file := FileLocator temp / url file.
self assert: file exists.
self assert: (signedFile match: url file).
file readStreamDo: [ :in | sha256 := SHA256 hashStream: in ]. “very slow”
self assert: (hash sameAs: sha256 hex).
Sven
Hi,
to understand the power they could have in their hand. Here is a testimony on the Pharo mailing-list. This is why we should build powerful new solutions in Pharo 🙂
Stef
Petr,
I’ve been working as a Consultant for many big corporations (mainly in VA Smalltalk) since 1996. The situation you describe is very well known to me. But in my opinion there is no technical reason for this. It’s a managerial problem. Ever since IBM went out to their customers and told them to move to Java for the better ini the mid-90ies, managers wanted the Smalltalk projects to go away as fast as possible. Nobody asked why IBM was still happily using VisualAge Smalltalk internally at that time frame….
So the Smalltalk projects were declared legacy by Management. Replacement projects were started with big efforts and optimism. Some went well, some somewhat came to fly in a bit more than double the time and much more times the costthan planned, some failed miserably. One thing was in common to the replacement projects all over the place: they took much longer, turned out to be much mor complicated and took a lot more manpower than anybody had ever imagined.
So two important things happened:
1) People were told the old Smalltalk stuff would be gone soon, so if you wanted to be a valued and appreciated staff member, you better stay away from these projects
2) The people who knew the business and technical side of the existing projects were moved to the new projects. Some liked it (because of 1) some were frustrated (because they knew / feared the new project was going to be a death march)
Over the first 2 years or so, nobody realized how bad the situation really was. It was easy to postpone user requirements to the new project, accumulate more and more manpower in the new project and still keep up green flags everywhere.
…until yellow was the new green and users/stakeholders wanted the new features NOW – and not one day when the replacement project would become real.
So the remaining manpower in the old project (not the ones with lots of experience and knowledge) had to extend the old system, integrate it with the new system (thereby implementing all the stuff that IBM once told their management would never be possible in Smalltalk) and keep it up and running year after year. Nobody ever said Thank You or would appreciate the work they did. Because that was old stuff anyways and was already irrelevant.
Some of these old systems still exist today, serving users every single day, while some of the new systems never appeared. No manpower was ever added to these projects, and never would anybody ever say: okay, guys, you won. They still work on legacy code and try to do their best to fulfill user requirements. While on other projects that never see the light of day, people get appreciation, are allowed to work with new technologies and do cool stuff. Nobody ever asked the Smalltalkers whether they could do that as well, because “if you want to do web, you need to do Java”. IBM said so, you know (and many other consultants as well).
So this is why new people try to stay away from these old projects. This is why the remaining staff is frustrated and this is why nobody allows them to do the cool things that Smalltalk can do as well as the others. They are just required to fix bugs, add new features in the old GUIs and else keep silent. Some of them were trying to fight this and tried to prove Smalltalk’s strengths, but back then nobody would listen. One day they gave up.
Management still frustrates people every. single. day.
Just my opinion
Joachim
Hi,
Weekly news about Pharo 