July 2016 - Pharo-dev - lists.pharo.org

A taste of bootstrap

by Pavel Krivanek

Hi, as you maybe know, we are working on Pharo image bootstrap - the process that can generate an image from source codes and initialize it correctly. Because of practical reasons we do not bootstrap the standard image at once but we are trying to bootstrap a small headless kernel image and then load the rest of the system into it. The good news is that we are successful in our effor. We are already able to produce well usable images as you can test here: https://goo.gl/fn1VbP >From the Pharo/Squeak point of view this image is very special because it doesn't contain any object inherited from 70's. Pharo lost its umbilical cord. Notice that the initial display width is too narrow and and we still need a lot of work on the building process, but In the next weeks and months it will change a lot the Pharo development - especially as soon as it will be combined with Git support. Cheers, -- Pavel

July 22, 2016

Re: [Pharo-dev] Pharo 6 image lockup at startup

by stepharo

Thanks for the bug report. Marcus is on vacation now (like me - I will start to integrate more issues as soon as I get a better network - here it is quite quite slow ;) and he will certainly have a look when he is back. Stef Le 20/7/16 Ã 17:16, Thierry Goubier a Ã©crit : > Hi guys, > > It seems there is a strange interaction between the deprecation > rewriter and image startup. > > If you load a package that has deprecated calls (command line loading: > without GUI), then save the image, the image will appear locked on the > next interactive start (black background on Linux). > > Loading the package by hand in an interactive image and saving a new > version with the deprecation rewritten solves the problem. > > Thierry

July 22, 2016

Re: [Pharo-dev] git feature request

by Peter Uhnak

On Fri, Jul 22, 2016 at 09:57:37AM +0000, Dimitris Chloupis wrote: > No. > > It may surprise you but pull requests having nothing to with code review, > they are just a formality. > > To understand pull requests you have to understand character of the person > that created git, Linus , the man behind Linux. Pull request is not a git concept and has nothing to do with git. It's an abstraction over merge. > easy going person, and he wanted a VCS that isolated developers rather than > bringing together under one roof as SVN is doing. Git was not the first DVCS; Linus & co. merely adopted system they were already using. > > Furthermore a pull request offers no practical advantage other than > isolation, you can review any commit done directly to the repo and revert > back the commits you dont like and open a discussion about it in the issue > tracker. This is factually false. Pull request is a group of interrelated commits, so while you can review individual commits, for anything larger than a bugfix reviewing individual commits is a waste of time. It's much easier to track changes and fixes after code reviews with a pull request. > And what makes pull request ever less uselful are branches Pull requests and branches are complementary. > Also pull requests come with a big disadvantage , fragmentation. Because > they lead to the creation of forks . Is this your first encounter with _distributed_ version control systems? Forks are fundamental aspect. > the fork only contains a handful of commits but a fork can easily deviate > without issuing any pull request back to main repo. Its similar to Squeak / > Pharo situation, the fork becoming more popular than the main repo. And in > the case on Squeak/Pharo is fine because the fork is only one, but a trip > to github disneyland will reveal a hell of forks especially for popular > repos. This can easily lead to "a war of forks". I don't see any problem here, it's OSS and people have different opinions, so forks are natural resolution. People often fork on github because they can or because they want to experiment with something, but there is no "war of forks". Running large OSS is resource-intense so common forks cannot and do not compete (e.g. bootstrap has 44000 forks, but none of them competes), And if they do compete then it's usually on fundamental opinion differences, or systemic problems that are best addressed with forks (e.g. lodash vs underscore). There is no problem with the fork surpassing it's predecessor, the community benefits from it in the long-term. Many different forks can be a pain for small under-maintained projects, because a fork can much more easily have an impactful change â so it's easy to have two or three forks with each having a different important feature. On the other hand due to it's small-scale, it can also usually be also resolved. If the original dev does not have the time and resources to manage it (which is too common since a lot of OSS are side-projects), then forks are inevitable. > Pull request essentially offer the advantage of isolation , when you have > hundred of developers trying to commit to the project you need some way to > keep the ones that you are not familar with out, this is why all very big > projects in github use pull requests but also have main contributors. For > much smaller projects say 5-10 people its not neccessary, since most likely > they will work in branches anyway and because merging to master will be > followed after a discussion in the issue tracker. We've successfully used pull requests in my previous company for years even on two-man projects, because they _can_ and do provide value. If you don't see it, or they are not valuable to you that's fine (Which can be easily true if you are a single dev/hobby programmer), but claiming that they are useless is just bullshit. Peter > > On Fri, Jul 22, 2016 at 11:17 AM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > On Fri, Jul 22, 2016 at 07:19:09AM +0000, Dimitris Chloupis wrote: > > > I see a pull request as a way to moderate commits by people that cannot > > be > > > trusted or that are not regular contributors. > > > > No. > > > > The purpose of pull request is to discuss and review the code. > > Code reviews should be done whether you are regular contributor or not, > > because it's valuable for both the code base, and all people involved. > > > > Furthermore if you have CI properly configured, then it can execute tests > > on the pull request so you know the code is healthy. > > > > Of course if you work alone or have this is a fun OSS side-project, then > > no rules apply. > > > > Peter > > > >

July 22, 2016

[Ann] ObjectTravel. A tool to traverse object references

by Denis Kudriashov

Hi. This is side project of my work on Seamess and RemoteDebuggingTools. You can load it by: Gofer it smalltalkhubUser: 'Pharo' project: 'ObjectTravel'; configuration; loadStable ObjectTravel is a tool to deeply traverse "native" references of given object through instance variables and "array contents". Usage is quite simple: traveler := ObjectTraveler on: (1@2 corner: 3@4). traveler referencesDo: [:eachRef | eachRed logCr]. Here is list of suitable methods: - collectReferences - countReferences - skip: anObject - traverseOnly: predicateBlock - copyObject - findAllPathsTo: targetObject - replaceCurrentReferenceWith: anObject Details are here http://dionisiydk.blogspot.fr/2016/07/objecttravel-tool-to-traverse-object.… . Best regards, Denis

July 22, 2016

Re: [Pharo-dev] [Pharo-users] [ANN] JSONWebToken

by Norbert Hartl

> Am 22.07.2016 um 11:47 schrieb Holger Freyther <holger(a)freyther.de>: > > >> On 22 Jul 2016, at 16:17, Norbert Hartl <norbert(a)hartl.name> wrote: >> > > > Hi! > >> Taking the assumption of having 20 service images, every image would need to get back to A in order to check authorization information. The more services images you have the more load it will put on A. In a JWT use case scenario the same would look like >> >> 1. client C authenticates and receives a JWT containing authorization information. The token is signed by A >> 2. client C hands out JWT to service S >> 3. S checks the signature of A and knows that the authorization information contained is valid. >> 4. S grants C access > > thank you for the information! I have one rather specific question. How is the token normally transported from C to S? Part of the body/data of a POST/PUT/GET? A custom header inside the HTTP request? It is up to you how you like to do it. It could be: - Client C asks A for authorization and gets back a JWT in the response body - Client C adds the JWT token as HTTP Header "Authorization: Bearer [token]" to ask the service in a usual fashion - Service S checks signature of token and extracts permission set and grants them or - Client C asks service S to do something - Service S redirects C to A giving a redirect_url as query parameter in the url - A checks authorization with C and then redirects the request to the request_uri having the token as query parameter of the uri or - Client C asks service S to do something - Service S redirects C to A giving a redirect_url as query parameter in the url - A checks authorization with C and then redirects the request to the request_uri having an exchange code in the query parameters - S exchange at A the exchange code with authorization token There are plenty of scenarios possible. It depends if it is about authorization or authentication and which "standard" to use. You can always roll your own. If you have many services it could be feasible to combine all permissions you need into one JWT then send it to A. If your claims are valid you get back the signed token from A. You could then use the same token for all your servicesâ¦. Hope this helps, Norbert

July 22, 2016

Re: [Pharo-dev] git feature request

by Dimitris Chloupis

No. It may surprise you but pull requests having nothing to with code review, they are just a formality. To understand pull requests you have to understand character of the person that created git, Linus , the man behind Linux. He is not exactly the most easy going person, and he wanted a VCS that isolated developers rather than bringing together under one roof as SVN is doing. Its not very suprising when you consider the size and complexity of Linux kernel and his not so polite character. Furthermore a pull request offers no practical advantage other than isolation, you can review any commit done directly to the repo and revert back the commits you dont like and open a discussion about it in the issue tracker. Github also offer several other tools, like comments on commits , gist for easy pasting of experimental code etc etc And what makes pull request ever less uselful are branches, git already offers a form of isolation, you can create your own branch in the repo that wont affect the master branch, you can open then a discussion on the issue tracker and you or some other merge the branch to the master branch. Usually master branch is the unstable version anyway , an additional stable branch is usually created for the end users. Also pull requests come with a big disadvantage , fragmentation. Because they lead to the creation of forks . That is not a problem by itself when the fork only contains a handful of commits but a fork can easily deviate without issuing any pull request back to main repo. Its similar to Squeak / Pharo situation, the fork becoming more popular than the main repo. And in the case on Squeak/Pharo is fine because the fork is only one, but a trip to github disneyland will reveal a hell of forks especially for popular repos. This can easily lead to "a war of forks". Pull request essentially offer the advantage of isolation , when you have hundred of developers trying to commit to the project you need some way to keep the ones that you are not familar with out, this is why all very big projects in github use pull requests but also have main contributors. For much smaller projects say 5-10 people its not neccessary, since most likely they will work in branches anyway and because merging to master will be followed after a discussion in the issue tracker. On Fri, Jul 22, 2016 at 11:17 AM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > On Fri, Jul 22, 2016 at 07:19:09AM +0000, Dimitris Chloupis wrote: > > I see a pull request as a way to moderate commits by people that cannot > be > > trusted or that are not regular contributors. > > No. > > The purpose of pull request is to discuss and review the code. > Code reviews should be done whether you are regular contributor or not, > because it's valuable for both the code base, and all people involved. > > Furthermore if you have CI properly configured, then it can execute tests > on the pull request so you know the code is healthy. > > Of course if you work alone or have this is a fun OSS side-project, then > no rules apply. > > Peter > >

July 22, 2016

Re: [Pharo-dev] [Pharo-users] [ANN] JSONWebToken

by Holger Freyther

> On 22 Jul 2016, at 16:17, Norbert Hartl <norbert(a)hartl.name> wrote: > Hi! > Taking the assumption of having 20 service images, every image would need to get back to A in order to check authorization information. The more services images you have the more load it will put on A. In a JWT use case scenario the same would look like > > 1. client C authenticates and receives a JWT containing authorization information. The token is signed by A > 2. client C hands out JWT to service S > 3. S checks the signature of A and knows that the authorization information contained is valid. > 4. S grants C access thank you for the information! I have one rather specific question. How is the token normally transported from C to S? Part of the body/data of a POST/PUT/GET? A custom header inside the HTTP request? kind regards holger

July 22, 2016

Re: [Pharo-dev] [ANN] JSONWebToken

by HernÃ¡n Morales Durand

Thank you for sharing Norbert. Best regards, HernÃ¡n 2016-07-22 5:17 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > Hi, > > thanks to the inquiry of Sven I published an implementation of > JSONWebToken to smalltalkhub. It is available at > > http://smalltalkhub.com/#!/~NorbertHartl/JSONWebToken > > For those who don't know JSONWebToken or short JWT pronounced "jot" is a > token format suitable for authentication and authorization. The token > consist of a header, a payload and a signature. The header defines crypto > algorithms, compression and other things needed to read a token on > reception. The payload is called a claim set which is basically a > dictionary with well-known and custom keys. If we think about OAuth or > OpenId the values contained map directly to JWT claims. For OpenID connect > which is an identification mechanism on top of OAuth the usage of JWT is > one of the building blocks. > > What are the advantages in using JWT? > > - it defines a header for encoding the content so it is quite flexible in > the ways compression and encryption of the key is done > - defines a payload which maps arbitrary keys and there is a set of > well-known keys that implementations of OAuth, OpenID can understand > - defines a signature that makes it easy to trust the information > contained or to give the token to someone who is not trusted > - token format is a single line string so it can be used e.g. in HTTP > authentication headers > > A problem JWT can solve: > > In our company we have a lot of little REST servers serving some duties. > To minimize the chaos I want to have a central authentication and > authorization point. If we assume having 20 images running and we look at > typical way how authorization works: > > there is image A (Authentication), image S (Service) und client C. Client > C wants to use the service S > > 1. client C authenticates and retrieves authorization information from A > (or from S which redirects him to A) > 2. client C hands out the authorization information to S > 3. S needs to check at A if the information is valid (client C could have > modified it or generated it) > 4. S grants C access > > Taking the assumption of having 20 service images, every image would need > to get back to A in order to check authorization information. The more > services images you have the more load it will put on A. In a JWT use case > scenario the same would look like > > 1. client C authenticates and receives a JWT containing authorization > information. The token is signed by A > 2. client C hands out JWT to service S > 3. S checks the signature of A and knows that the authorization > information contained is valid. > 4. S grants C access > > FYI, > > Norbert > >

July 22, 2016

Re: [Pharo-dev] [ANN] JSONWebToken

by Denis Kudriashov

2016-07-22 10:17 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: > > A problem JWT can solve: > > In our company we have a lot of little REST servers serving some duties. > To minimize the chaos I want to have a central authentication and > authorization point. If we assume having 20 images running and we look at > typical way how authorization works: > > there is image A (Authentication), image S (Service) und client C. Client > C wants to use the service S > > 1. client C authenticates and retrieves authorization information from A > (or from S which redirects him to A) > 2. client C hands out the authorization information to S > 3. S needs to check at A if the information is valid (client C could have > modified it or generated it) > 4. S grants C access > > Taking the assumption of having 20 service images, every image would need > to get back to A in order to check authorization information. The more > services images you have the more load it will put on A. In a JWT use case > scenario the same would look like > > 1. client C authenticates and receives a JWT containing authorization > information. The token is signed by A > 2. client C hands out JWT to service S > 3. S checks the signature of A and knows that the authorization > information contained is valid. > 4. S grants C access > Thank's for explanation Norbert. Now I don't need to google about it :)

July 22, 2016

[ANN] JSONWebToken

by Norbert Hartl

Hi, thanks to the inquiry of Sven I published an implementation of JSONWebToken to smalltalkhub. It is available at http://smalltalkhub.com/#!/~NorbertHartl/JSONWebToken <http://smalltalkhub.com/#!/~NorbertHartl/JSONWebToken> For those who don't know JSONWebToken or short JWT pronounced "jot" is a token format suitable for authentication and authorization. The token consist of a header, a payload and a signature. The header defines crypto algorithms, compression and other things needed to read a token on reception. The payload is called a claim set which is basically a dictionary with well-known and custom keys. If we think about OAuth or OpenId the values contained map directly to JWT claims. For OpenID connect which is an identification mechanism on top of OAuth the usage of JWT is one of the building blocks. What are the advantages in using JWT? - it defines a header for encoding the content so it is quite flexible in the ways compression and encryption of the key is done - defines a payload which maps arbitrary keys and there is a set of well-known keys that implementations of OAuth, OpenID can understand - defines a signature that makes it easy to trust the information contained or to give the token to someone who is not trusted - token format is a single line string so it can be used e.g. in HTTP authentication headers A problem JWT can solve: In our company we have a lot of little REST servers serving some duties. To minimize the chaos I want to have a central authentication and authorization point. If we assume having 20 images running and we look at typical way how authorization works: there is image A (Authentication), image S (Service) und client C. Client C wants to use the service S 1. client C authenticates and retrieves authorization information from A (or from S which redirects him to A) 2. client C hands out the authorization information to S 3. S needs to check at A if the information is valid (client C could have modified it or generated it) 4. S grants C access Taking the assumption of having 20 service images, every image would need to get back to A in order to check authorization information. The more services images you have the more load it will put on A. In a JWT use case scenario the same would look like 1. client C authenticates and receives a JWT containing authorization information. The token is signed by A 2. client C hands out JWT to service S 3. S checks the signature of A and knows that the authorization information contained is valid. 4. S grants C access FYI, Norbert

July 22, 2016