October 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Smalltalk Argument
by henry Oct. 28, 2017

Oct. 28, 2017

I confuse easily, as you say freeipa works wonderfully well, then point out sun support to the api is hidden and itâs tricky to use. Do you mean Hadoopâs use is iffy? If freeipa works wonderfully can we find the right api and sequence of calls, building our own model in image side? Then that model we compute on and it makes the right calls. Modeling is our strength, I have always thought. What is achievable? This would benefit ParrotTalk I think. - HH On Thu, Oct 26, 2017 at 16:28, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > There are two key Kerberos implementations one can use with Hadoop. > > One is the FreeIpa/RedHat IdM. > The other is ActiveDirectory. > > I am using FreeIPA which bundles MIT Kerberos/389/sssd and more for making a CA etc. Works wonderfullÃ½ well. > > AD is well ... part of the corporate landdscape. > > Most of Kerberos needs are done with Java in Hadoop. But details are buried in private Sun classes.. > > Google Madness beyond the gate hadoop for some Lovecraftian quotes describing the situation along educated info. > > Phil > > On Oct 26, 2017 18:23, "henry" <henry(a)callistohouse.club> wrote: > >> I have no idea which is best. For being able to say we use industry standard Kerberos, calling an accepted implementation seems wise, like OpenSSL support. >> >> - HH >> >> On Thu, Oct 26, 2017 at 11:39, Paulo R. Dellani <dellani(a)pobox.com> wrote: >> >>> This all sounds very interesting. What is the idea? Wrap libkrb5 through UFFI or implement it in Smalltalk? >>> >>> On 10/26/2017 04:38 PM, henry wrote: >>> >>>> A Kerberos effort will have to be a group effort. Sideways to my main focus and your allâs main focii. >>>> >>>> - HH >>>> >>>> On Thu, Oct 26, 2017 at 09:15, henry <henry(a)callistohouse.club> wrote: >>>> >>>>> I think another good service to integrate well to is Elastic Search. >>>>> >>>>> Of the 4 types of integration, I vote for and step forward to volunteer to help Kerberos integration in Pharo. What to do? >>>>> >>>>> - HH >>>>> >>>>> On Thu, Oct 26, 2017 at 09:06, henry <henry(a)callistohouse.club> wrote: >>>>> >>>>>> I try posting with a smaller image. >>>>>> >>>>>> [""hubbub.jpg""] >>>>>> >>>>>> - HH >>>>>> >>>>>>> âââ Original Message âââ >>>>>>> Subject: Re: [Pharo-users] Smalltalk Argument >>>>>>> Local Time: October 26, 2017 8:52 AM >>>>>>> UTC Time: October 26, 2017 12:52 PM >>>>>>> From: henry(a)callistohouse.club >>>>>>> To: phil(a)highoctane.be [<phil(a)highoctane.be>](mailto:phil@highoctane.be), Any question about pharo is welcome [<pharo-users(a)lists.pharo.org>](mailto:pharo-users@lists.pharo.org) >>>>>>> >>>>>>> Perhaps not, or not yet. Perhaps it is the communications foundation for an always-on cloud/bigData control layer. >>>>>>> >>>>>>> I would position ParrotTalk as a Kerberos transport. ParrotTalk does 2048-bin key negotiation and subsequent encryption/encoding, both user-supplied. >>>>>>> >>>>>>> Please see the attached diagram, co-locating ParrotTalk with my other components. >>>>>>> >>>>>>> ParrotTalk does not do user authentication/authorization. Which means to me that I should consider Kerberos authorization/authentication to establish as an integratable transport to play in bigData. >>>>>>> >>>>>>> This means you still need a Kerberos client and I need a Kerberos client. How do we start? >>>>>>> >>>>>>> - HH >>>>>>> >>>>>>> PS: I did much work integrating Kafka into a framework. I was thinking of inserting msg sending replication to a partition count of replicate queues for sending and receiving Hubbub traffic, thus inserting right where Kerberos is in the diagram. I would love to see client coupling for Kerberos, Kafka and Hadoop, while I figure out proper security to make that group happy with this as a possible control layer solution, forking off jobs. >>>>>>> >>>>>>> On Thu, Oct 26, 2017 at 03:14, phil(a)highoctane.be <phil(a)highoctane.be> wrote: >>>>>>> >>>>>>>> Sure. Current main issue is to have Pharo work with Kerberos as secured Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole of crypto things. >>>>>>>> >>>>>>>> How would you see ParrotTalk work? >>>>>>>> >>>>>>>> I made a XmppTalk thing (binding for libstrophe) for having Pharo images and other stuff talk together (currently using OpenFire/Gajim/Profanity) FWIW >>>>>>>> >>>>>>>> See https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1… >>>>>>>> >>>>>>>> libstrophe does the SSL thing under the hood (using OpenSSL) and is actively maintained. >>>>>>>> https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c >>>>>>>> >>>>>>>> And I currently work with Kafka so, Pharo as a consumer or producer, sure am interested. But need Kerberos support. >>>>>>>> >>>>>>>> Tell me more about your vision. Even better, draw it in some way :-) >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> On Thu, Oct 26, 2017 at 8:43 AM, henry <henry(a)callistohouse.club> wrote: >>>>>>>> >>>>>>>>> This is a goal of ParrotTalk, to bring bit-compatible communications to Squeak, Pharo and Java. This is not an invocation bridge you speak of but a communications bridge to be able to run against Hadoop or whichever big data needs integration with (Kafka). I had hoped it might be adopted for such. Yet again this is not exactly what you were looking for but yet interesting perhaps? >>>>>>>>> >>>>>>>>> - HH >>>>>>>>> >>>>>>>>> On Thu, Oct 26, 2017 at 02:17, phil(a)highoctane.be < phil(a)highoctane.be> wrote: >>>>>>>>> >>>>>>>>>> I like that piece a lot, seeing exactly the described situation in large enterprises. >>>>>>>>>> >>>>>>>>>> I made a strategic decision to go with Pharo for the long run for my solutions because it is a stable base on which to build (ok, there are evolutions, but fundamentally, I can rely on it being under control and can maintain solutions in a version). >>>>>>>>>> >>>>>>>>>> The rationale is that at a deep level I am really fed up with having to deal with accidental complexity (now having to deal with Spark/Scala/sbt/Java/maven stuff) that makes the dev focus 80% technology drag and 20% net business contribution. >>>>>>>>>> >>>>>>>>>> One key thing is that a team needs guidance and Smalltalk makes it easier due to well known ways of doing things. >>>>>>>>>> >>>>>>>>>> Now we miss the boat on mobile and bigdata, but this is solvable. >>>>>>>>>> >>>>>>>>>> If we had an open Java bridge (and some people in the community have it for Pharo but do not open source it - so this is eminently doable) + Pharo as an embeddable piece (e.g. like Tcl and Lua) and not a big executable we would have a way to embed Pharo in a lot of places (e.g. in the Hadoop ecosystem where fast starting VMs and small footprint would make the cluster capacity x2 or x3 vs uberjars all over the place) this would be a real disruption. >>>>>>>>>> >>>>>>>>>> Think about being able to call Pharo from JNA https://github.com/java-native-access/jna the same way we use C with UFFI. >>>>>>>>>> >>>>>>>>>> Smalltalk argument for me is that it makes development bearable (even fun and enjoyable would I say) vs the other stacks. That matters. >>>>>>>>>> >>>>>>>>>> Phil

2 1

Enterprise authentication with Kerberos (was Re: Smalltalk Argument)
by Ben Coman Oct. 28, 2017

Oct. 28, 2017

Kerberos deserves its own topic rather than mixing in with the Smalltalk Argument one that now stands at 53 posts. Hopefully I've managed to extract pertinent parts of this thread. On Thu, Oct 26, 2017 at 3:14 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Sure. Current main issue is to have Pharo work with Kerberos as secured > Hadoop uses the UGI (UserGroupInformation) thing and that is a black hole > of crypto things. > > How would you see ParrotTalk work? > > I made a XmppTalk thing (binding for libstrophe) for having Pharo images > and other stuff talk together (currently using OpenFire/Gajim/Profanity) > FWIW > > See https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tm > uxyZz1UaX5ikEU/edit?usp=sharing > > libstrophe does the SSL thing under the hood (using OpenSSL) and is > actively maintained. > https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c > > And I currently work with Kafka so, Pharo as a consumer or producer, sure > am interested. But need Kerberos support. > > Tell me more about your vision. Even better, draw it in some way :-) > > Phil > On Thu, Oct 26, 2017 at 8:52 PM, henry <henry(a)callistohouse.club> wrote: > Perhaps not, or not yet. Perhaps it is the communications foundation for > an always-on cloud/bigData control layer. > > I would position ParrotTalk as a Kerberos transport. ParrotTalk does > 2048-bin key negotiation and subsequent encryption/encoding, both > user-supplied. > > Please see the attached diagram, co-locating ParrotTalk with my other > components. > > ParrotTalk does not do user authentication/authorization. Which means to > me that I should consider Kerberos authorization/authentication to > establish as an integratable transport to play in bigData. > > This means you still need a Kerberos client and I need a Kerberos client. > How do we start? > > - HH > > PS: I did much work integrating Kafka into a framework. I was thinking of > inserting msg sending replication to a partition count of replicate queues > for sending and receiving Hubbub traffic, thus inserting right where > Kerberos is in the diagram. I would love to see client coupling for > Kerberos, Kafka and Hadoop, while I figure out proper security to make that > group happy with this as a possible control layer solution, forking off > jobs. > On Thu, Oct 26, 2017 at 9:15 PM, henry <henry(a)callistohouse.club> wrote: > I think another good service to integrate well to is Elastic Search. > > Of the 4 types of integration, I vote for and step forward to volunteer to > help Kerberos integration in Pharo. What to do? > > On Thu, Oct 26, 2017 at 10:38 PM, henry <henry(a)callistohouse.club> wrote: > A Kerberos effort will have to be a group effort. Sideways to my main > focus and your allâs main focii. On Thu, Oct 26, 2017 at 11:39 PM, Paulo R. Dellani <dellani(a)pobox.com> wrote: > This all sounds very interesting. What is the idea? Wrap libkrb5 through > UFFI or implement it in Smalltalk? > On Fri, Oct 27, 2017 at 6:06 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > There are two key Kerberos implementations one can use with Hadoop. > > One is the FreeIpa/RedHat IdM. > The other is ActiveDirectory. > > I am using FreeIPA which bundles MIT Kerberos/389/sssd and more for making > a CA etc. Works wonderfullÃ½ well. > > AD is well ... part of the corporate landdscape. > > Most of Kerberos needs are done with Java in Hadoop. But details are > buried in private Sun classes.. > > Google Madness beyond the gate hadoop for some Lovecraftian quotes > describing the situation along educated info. > > Phil > > On Thu, Oct 26, 2017 at 6:23 PM, henry <henry(a)callistohouse.club> wrote: > >> I have no idea which is best. For being able to say we use industry >> standard Kerberos, calling an accepted implementation seems wise, like >> OpenSSL support. > > On Sat, Oct 28, 2017 at 4:51 AM, henry <henry(a)callistohouse.club> wrote: > How about Kerberos? Can we get a team to look closely at bringing > integration for enterprise users? That would be helpful, or can you just > put it behind a Kerberos wrapper? If that would work, collecting a demo, > that could unlock more corporate wallets , for investment. > > - HH >

1 1

Re: [Pharo-users] [GT] moldable tools for non-developers
by Offray Vladimir Luna CÃ¡rdenas Oct. 27, 2017

Oct. 27, 2017

Hi, On 27/10/17 10:48, Sebastian Heidbrink via Pharo-users wrote: > While the ambitions behind GT seem to be developer centric, I wonder > if there is also research or development done to support non-developer > pharo users. Yes. We're trying to bridge the gap between developers and non-developers (like myself) using moldable environments like Pharo. Our use case is data activism, visualization and storytelling. So our intended users are people coming from any of such fields that don't develop app, but try to tell factual stories supported by data and/or visualizations. For that I have developed the Grafoscopio[1] tool and the Data Week workshop+hackathon [2], were we approach the gap between devs and other users from the point of critical data & software literacy (pretty far away from the "Hello World" introduction to programming[3]). [1] http://mutabit.com/grafoscopio/index.en.html [2] http://mutabit.com/dataweek/ [3] http://mutabit.com/offray/blog/en/entry/dumb-hello-world Pharo, agile visualization and moldable tools have allowed me to explore my PhD question about "How we can change the digital tools that change us?" from this critical approach to data/tech, tools and literacy for/from activism. Cheers, Offray

2 1

[GT] moldable tools for non-developers
by Sebastian Heidbrink Oct. 27, 2017

Oct. 27, 2017

Hi all! There is this strong movement within Pharo now, that allows developers to expand the individual development process with the help of moldable dev tools based on GlamourToolkit (GT). This allows for a much more effective communication between stakeholders and developers resulting in a more cost effective development. While the ambitions behind GT seem to be developer centric, I wonder if there is also research or development done to support non-developer pharo users. Are there projects that try to integrate/interface "modeling" into/with GT? (e.g. likeÂ STELLA [1]) I am also wondering if aspect oriented programming could help closing the full cycle of an adaptive development/management process. Anybody researching on something like this? Thank you for any hint! Sebastian [1] https://www.iseesystems.com/

1 0

[ANN] Pharo Consortium New Platinum Member: JPMorgan Chase
by Marcus Denker Oct. 27, 2017

Oct. 27, 2017

The Pharo Consortium is very happy to announce that JPMorgan Chase has joined the Consortium as a Platinum Member. About - JPMorgan Chase: https://www.jpmorganchase.com - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

2 1

Cryptography and hashing in Pharo
by CÃ©drick BÃ©ler Oct. 27, 2017

Oct. 27, 2017

Hi again, Concerning cryptography in Pharo, there are to my knowledge : => a package developed in squeak [1] that was I think ported/forked for Pharo. I cannot find the Pharo version => a binding to the sodium library (NaCl) [2] With one would you recommend ? Maybe another option ? Concerning hashing (Iâd like to hash information content a bit like this is done in ifs with their multihash lib [3]) => I found a keccak implication with I think would do the [4]. Any feedback ? Other implementations available ? => Do you think having something like ifs multihash would be interesting in Pharo ? Again, thanks in advance for your comments/advices. CÃ©drick [1] http://www.squeaksource.com/Cryptography.html <http://www.squeaksource.com/Cryptography.html> [2] http://catalog.pharo.org/catalog/project/Nacl?_s=54MCZlmxc6F08Ht4&_k=HxcBD1… <http://catalog.pharo.org/catalog/project/Nacl?_s=54MCZlmxc6F08Ht4&_k=HxcBD1…> [3] https://github.com/multiformats/multihash <https://github.com/multiformats/multihash> [4] https://github.com/sbragagnolo/Keccak <https://github.com/sbragagnolo/Keccak>

2 3

"sourcetrail" a code browser for C++/Java
by Holger Freyther Oct. 27, 2017

Oct. 27, 2017

Hi, I was just watching some videos and stumbled across sourcetrail[1][2]. The visualizations look pretty neat. Maybe it can be used an inspiration? cheers holger [1] https://www.youtube.com/watch?v=r8S6V6U5Vr4 [2] https://www.sourcetrail.com

1 0

Annual online conference?
by PAUL DEBRUICKER Oct. 26, 2017

Oct. 26, 2017

Laravel.com is a PHP web framework. Their community organizes an online conference: https://laracon.net/2017 Seems like it could be worthy of mimicking in the Smalltalk community.

4 3

Re: [Pharo-users] Glorp: #includesKey:
by Herby VojÄÃk Oct. 25, 2017

Oct. 25, 2017

Niall Ross wrote: > Dear Herby, > adding #includesKey: is certainly doable. If you look at callers above > and subcallers below #anySatisfyDefault: you will see the issues > involved. Your includesKey: needs the same degree of platform-awareness > that Glorp's #anySatisfy: and #allSatisfy: implementations use. But > since #anySatisfy: is there, you have a ready template to follow. I don't feel competent enough, from what I looked, Glorp innards are a bit complex. > Alternatively, I may well add #includesKey: - though not as my most > urgent task. :-) I did a fair amount of work to extend the usability of > DictionaryMappings in Glorp three years ago (part of demonstrating the > ObjectStudio business-mapping/Glorp-generating tools - see my ESUG 2014 > presentation for details) but I did not then think of providing > #includesKey:. Thanks for suggesting the idea. My pleasure. :-) As I wrote elsewhere, also #keys is something (probably the most general) one that could be added as a matter of allowing to work with the key field - as far as I was able to find out, there is no way to actually get to the key, for which I found workaround since I mapped object, but would be out of luck if I mapped single primitive value. For the moment, it is not pressing, but yes, it would be nice to be able to have #keys mapping to key field and #includesKey: as an idiomatic way to do keys includes:. Thanks again, Herby > If you were to work on this, be aware: > > - always reinitialise FunctionExpression class after adding/changing any > Glorp function (or just close and reopen your image, of course) > > - If (and only if) you construct Query whereClauses in stages (e.g. you > have code like > > myQuery AND: [:customer | customer orders includesKey: #onlineOrders] > > or similar) then, using its callers in GlorpTest as a guide, know when > you might need to send #setUpBaseFromSession: to your query while doing > so. (N.B. that method is a Glorp version 8.2.1 addition; you will not > have it in older Glorp.) The point is that stage-constructed where > clauses must convert from block to expression before execution, to > combine the stages. Any that use #anySatisfy:/#allSatisfy: need > platform-specific information to do this; I would expect any > #includesKey: implementation to be the same. > > HTH > Niall Ross > > > Tom Robinson wrote: > > Hi Herby, > > In my opinion, the way you found to make it work is the way it should > be. The reason is that the first way doesn't translate into SQL and the > second one does. It might be possible to add includesKey: functionality > but resolving that to SQL would be more complex. I would not call this a > bug. I would call it a limitation of the implementation. I don't know of > anyone planning to add this feature to Glorp right now. > > Regards, > > Tom > > On 10/24/2017 12:27 PM, Herby VojÄÃk wrote: > >> Hello! >> >> I am using a DictionaryMapping in my code, and I wanted to use >> #includesKey: in #where: clause (something akin >> >> each tools includesKey: aToolId >> >> ) to select only rows for which DictionaryMapping uses certain key. It >> failed with the error in the lines of "#tools does not resolve to >> field". I had to come up with >> >> each tools anySatisfy: [ :tool | tool id = aToolId ] >> >> Is it the bug / feature / problem in my approach? If bug, is it >> planned to add #includesKey: translation to DictionaryMapping? >> >> Thanks, Herby >

1 0

Glorp: #includesKey:
by Herby VojÄÃk Oct. 25, 2017

Oct. 25, 2017

Hello! I am using a DictionaryMapping in my code, and I wanted to use #includesKey: in #where: clause (something akin each tools includesKey: aToolId ) to select only rows for which DictionaryMapping uses certain key. It failed with the error in the lines of "#tools does not resolve to field". I had to come up with each tools anySatisfy: [ :tool | tool id = aToolId ] Is it the bug / feature / problem in my approach? If bug, is it planned to add #includesKey: translation to DictionaryMapping? Thanks, Herby

2 2