[Pharo-users] Smalltalk Argument

[Paulo R. Dellani]

Dear all,

after using Smalltalk for several years I developed a passion for the
language (how not to?), and Pharo is just so great to develop with.
So thank you guys for keeping this wonderful project running.

Unfortunately, it is not easy to always point out why Smalltalk
should be employed as "main development language" in a team
or for a project. In the last discussion of this sort I was confronted
with the question "where are we going to get new smalltalk
developers if our startup grows or if you go?". Well, I had no
good answer to that. What would have you answered?

Cheers,

Paulo

Re: [Pharo-users] LGit_GIT_ERROR: Invalid version 0 on git_remote_callbacks on latest 64bit 6.1 image?

[Paulo R. Dellani]

You need to configure Iceberg with the path of the SSH key
files you are using to authenticate with gitlab as well as the
passphrase to unlock the private key, I only got it working
after that. Have your done that?

There is more information in the README/FAQ here:

https://github.com/pharo-vcs/iceberg

Cheers,

Paulo

On 11/08/2017 12:26 AM, Tim Mackinnon wrote:
> Thanks for confirming this Esteban - perhaps I am doing something
> wrong - I tried using the steps I was using successfully several
> months ago namely:
>
> curl get.pharo.org/64/  | bash
> ./pharo-ui Pharo.image
>
> Which got me the latest image - which sys info says is (not sure why
> it still says 6.0 tho?):
>
> Pharo 6.0
> Latest update: #60520
>
> I then open Iceberg, and click on Clone Repository
>
> In the dialog I enter:
>
> g...@gitlab.com :macta/PharoLambda.git
> And put src in the code subdirectory field, and then click on Create.
>
> I get the LGit_GIT_ERROR ???
>
> Hmm, out of curiosity, I just tried leaving the src field empty and it
> then seemed to put an entry into Iceberg but then a Fetch gave me the
> same error?
>
> Tim
>
>> On 7 Nov 2017, at 11:46, Esteban Lorenzano > > wrote:
>>
>> iceberg should work on 64bits, both on Pharo7 and Pharo6. 
>> I’ve been using it exclusively on 64bits since some months now and I
>> know I’m not the only one… can you send a way to reproduce your
>> problem so I can take a look?
>>
>> Esteban
>>
>>
>>> On 6 Nov 2017, at 12:11, Tim Mackinnon >> > wrote:
>>>
>>> Hi - does Iceberg work on a 64bit image yet? I’ve not tried in a
>>> while, and was surprised when I went to get a new image via the
>>> command line that I am getting the error: LGit_GIT_ERROR: Invalid
>>> version 0 on git_remote_callbacks
>>>
>>> I can see a post by Alistair in Jun asking about this, and it seems
>>> 64bit hadn’t been updated to work back then - but is this still true
>>> in Nov?
>>>
>>> We seem very much in turmoil at the moment - and its unclear what
>>> should work and not work. Is there a stable platform? If 64 bit is
>>> only working for 7.x - should we remove it from 6.x so that people
>>> don’t inadvertently try to use it?
>>>
>>> Tim
>>
>

Re: [Pharo-users] Exchanging information between 2 pharo applications (2 images running on two different computers)

[Paulo R. Dellani]

Dear all,

I would like to give ZeroMQ a try in Smalltalk, but am unable to
load it on a new image successfully. In Pharo 5, I loaded the package
ConfigurationOfZeroMQ from therepository in smalltalkhub
 and
evaluated the following to load the code:

ConfigurationOfZeroMQ loadBleedingEdge

It seems to load everything well, but when I try to look at the source
code of the methods that call the C routines from libzmq using the
system browser, the system exhibits the following error message:

UndefinedObject(Object)>>doesNotUnderstand: #keywords
RBFFICallPragma(RBPragmaNode)>>selectorParts
RubSHTextStylerST80(SHRBTextStyler)>>visitPragmaNode:
RBFFICallPragma(RBPragmaNode)>>acceptVisitor:
RubSHTextStylerST80(SHRBTextStyler)>>visitNode:
[ :each | self visitNode: each ] in
RubSHTextStylerST80>>visitMethodNode: in Block: [ :each | self
visitNode: each ]
OrderedCollection>>do:

(its a long stack, cutting here)

When loading ZeroMQ on Pharo 6, a window pops-up with the title
'Syntax Error: Literal constant expected' showing the source code
of a method defining a call to a routine from a C library:

apiDeleteDC: aHDC
     bool 'DeleteDC' (Win32HDC)
module:'gdi32.dll'>
    ^self externalCallFailed

If I update the syntax, re-writing the code above as

apiDeleteDC: aHDC
    ^self ffiCall: #( bool DeleteDC (Win32HDC aHDC) ) module:'gdi32.dll'

the compiler accepts it and the process can go on, but eventually
the system will become unstable...

Any ideas on how to solve this problems? Is this syntax still supported
in Pharo5 & 6?

Cheers,

Paulo

On 10/25/2017 03:47 PM, Sebastian Heidbrink via Pharo-users wrote:
> ForwardedMessage.eml
>
> Subject:
> Re: [Pharo-users] Exchanging information between 2 pharo applications
> (2 images running on two different computers)
> From:
> Sebastian Heidbrink 
> Date:
> 10/25/2017 03:47 PM
>
> To:
> pharo-users@lists.pharo.org
>
>
> Hi Cederik,
>
> you should have a look at http://smalltalkhub.com/#!/~panuw/zeromq
> ZeroMQ is a networking library. Nice thing about it is that all the
> networking related workload is dealt with in a second process. That
> can save you some resources within Smalltalk.

[Pharo-users] Return value of a FFI call to a external function is its 2`s complement

[Paulo R. Dellani]

Dear uFFI experts,

I am dealing with the port of the ZeroMQ
 code to Pharo 6 and found
something unexpected to me, at least:

Zmq4Api>>apiZmqMsgRecv: message socket: socket withFlags: flags
    ^ self ffiCall: #(long zmq_msg_recv (ZmqApiMessage* message,
ZmqApiSocket* socket, long flags ) )

Calling this returns the 2's complement of the return value
of the external function call. Is it expected that the code calling
this do the decoding of the 2'complement representation of
the return value?

Cheers,

Paulo

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

[Paulo R. Dellani]

P.S.: some details of the setup follow.

pharo --version:

5.0-201707201942  Thu Jul 20 20:40:54 UTC 2017 gcc 4.6.3 [Production
Spur 64-bit VM]
CoInterpreter VMMaker.oscog-eem.2254 uuid:
4f2c2cce-f4a2-469a-93f1-97ed941df0ad Jul 20 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid:
2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017
VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Date: Thu Jul 20 12:42:21 2017 -0700 $
Plugins: 201707201942
https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Linux testing-gce-74d10329-bbfd-42e5-8995-b0e3a68c73cb
3.13.0-115-generic #162~precise1-Ubuntu SMP Fri Mar 24 16:47:06 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
plugin path: /opt/smalltalk/pharo6.1/pharo-vm/lib/pharo/5.0-201707201942
[default: /opt/smalltalk/pharo6.1/pharo-vm/lib/pharo/5.0-201707201942/]

uname -a

Linux neutrino 4.13.8-100.fc25.x86_64 #1 SMP Wed Oct 18 17:10:31 UTC
2017 x86_64 x86_64 x86_64 GNU/Linux


On 10/30/2017 01:02 PM, Paulo R. Dellani wrote:
> Dear uFFI experts,
>
> I am dealing with the port of the ZeroMQ
> <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> code to Pharo 6 and found
> something unexpected to me, at least:
>
> Zmq4Api>>apiZmqMsgRecv: message socket: socket withFlags: flags
>     ^ self ffiCall: #(long zmq_msg_recv (ZmqApiMessage* message,
> ZmqApiSocket* socket, long flags ) )
>
> Calling this returns the 2's complement of the return value
> of the external function call. Is it expected that the code calling
> this do the decoding of the 2'complement representation of
> the return value?
>
> Cheers,
>
> Paulo

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

[Paulo R. Dellani]

"Two`s complement" is one possible way to represent signed integers in
binary form (1).

When the message apiZmqMsgRecv: message socket: socket withFlags:
flagsis sent, as
shown in my prior message, a function from libzmq, zmq_msg_recv (2) is
called
and the return value should be either the number of bytes in the
received message
or -1, in case of an error. Well, I was expecting to get a -1 as return
value when
calling the function in non-blocking mode, but it returns 0x,
which happens
to be the 2's complement representation of -1. At least the old code for
libZMQ
was not expecting that.

Cheers, Paulo

(1) https://en.wikipedia.org/wiki/Two's_complement
(2) http://api.zeromq.org/4-2:zmq-msg-recv

On 10/30/2017 02:13 PM, Dimitris Chloupis wrote:
>
> I have no idea what you mean by "2's complement" 
>
> In any case bare in mind that UFFI has a limited range of C types that
> does support. Here you use 2 custom types , ZmqApiMessage and
> ZmqApiSocket , both are pointers because of * . Now these types are
> definetly not included with UFFI so if you have not done so you will
> have to
>  
> 1) Define a class that inherits from FFIExternalObject and make sure
> your class handles the pointer properly 
> 2) Replace the custom type with an equivelant type that is supported
> by UFFI
>
> The type of the pointer does not affect the pointer itself, usually,
> but rather the data it points to. So a pointer knows from it type that
> the data consumes a x amount of bytes and is of specific type , this
> can help also with indexing as C arrays are nothing more than a
> pointer that uses the index as an offset depending on its type of x
> amount of bytes. 
>
> So its crucial that you get these right or else you going have some
> super weird results and even crashes. 
>
> Because if you use improper types the pointer will give access to an
> area of memory bigger or smaller than the inteded type . Smaller will
> give you corrupted data (you will be missing bytes of data), bigger
> may crash because it may extend to area of memory not allowed to access. 
>
> Technically speaking you can use even incorrect types if you know what
> you doing because UFFI pointers have great flexibility allowing you
> define real time the excact position of the memory and the range. 
>
> Bare in mind that C is a high level language (and not low level as
> many incorrect assume) and deal with types that is NOT a low level
> concept (excepts types that have to do only with the size/ amount of
> bits) . So the type gives crucial information to C how exactly to
> access the memory. 
> On Mon, Oct 30, 2017 at 2:03 PM Paulo R. Dellani <dell...@pobox.com
> <mailto:dell...@pobox.com>> wrote:
>
> Dear uFFI experts,
>
> I am dealing with the port of the ZeroMQ
> <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> code to Pharo 6 and
> found
> something unexpected to me, at least:
>
> Zmq4Api>>apiZmqMsgRecv: message socket: socket withFlags: flags
>     ^ self ffiCall: #(long zmq_msg_recv (ZmqApiMessage* message,
> ZmqApiSocket* socket, long flags ) )
>
> Calling this returns the 2's complement of the return value
> of the external function call. Is it expected that the code calling
> this do the decoding of the 2'complement representation of
> the return value?
>
> Cheers,
>
> Paulo
>

Re: [Pharo-users] Return value of a FFI call to a external function is its 2`s complement

[Paulo R. Dellani]

Hi Pablo,

correcting the type declaration in the ffiCall solved the problem, thanks!

Cheers,

Paulo

On 10/30/2017 05:24 PM, teso...@gmail.com wrote:
> Hi, 
>  the problem is that the Zq function has the following signature:
>
> int zmq_msg_recv (zmq_msg_t *msg, void *socket, int flags);
>
> And in your ffiCall you are putting #long. 
>
> You should use the correct size of integers, as the binary numbers
> need to extend the size when they are negatives. 
>
> 0x is a valid positive for a long, but a -1 for an int. 
>
> Cheers.
>
>
> -- 
> Pablo Tesone.
> teso...@gmail.com 

Re: [Pharo-users] Smalltalk Argument

[Paulo R. Dellani]

I like your depiction of the situation and arguments, Andrew.

The inherent volatility of the software industry due to its tendency
to self disruption, as you pointed out, is fertile ground to all kinds of
crap, but we as developers should keep our eyes wide open and
look for the pearls and gems that grow here and there,
like Pharo Smalltalk.

Of course my "vision", as a Smalltalker is inherently biased, but
as you said, when "shit has to work", I think that we have good
cards at our hands.

So yesterday we had another meeting and I think I could make a
good point for Smalltalk, thanks to all your arguments here at the
list. But surely the absolute killer argument is that "this shit really
works" :-)

As pointed out by several of you, integration is key. For my particular
present case, I could successfully integrate the developed tools in
the system, a medical imaging processing pipeline, through the
command line and the filesystem - so no need for fancy looking web
apps at the moment, but it surely will not hurt to have this possibilities
- it would be cool to run part of the code at the front end (internet
browser),
in our case, some pre-processing of medical data before it is sent
to the "main processing pipeline" (just one practical example of
many other possible applications). This particular task could be done
with Javascript, but I am afraid that the necessary libraries are not
so good..

Cheers,

Paulo

On 10/26/2017 12:46 AM, Andrew Glynn wrote:
>
> There’s other questions that are relevant to me:
>
>  
>
> Do I give a f*** about cool looking web apps?  No, I don’t use web
> apps if in any way I can avoid it.
>
>  
>
> Do I give a f*** about mobile apps?  No, the screen’s too small to
> read anything longer than a twit, or anyone with anything worthwhile
> to say.
>
>  
>
> Do I give a f*** about the number of libraries in other languages? 
> No, because most of them are crap in every language I’ve had to work
> in, and the base languages are crap so they have to keep changing
> radically, and libraries and frameworks therefore also have to and
> never get any better. The few that are worthwhile I can almost always
> use from Smalltalk without a problem (read, Blender, ACT-R and
> Synapse, since every other library/framework I’ve used outside
> Smalltalk has been a waste of time). 
>
>  
>
> Do I give a f*** about implementing a complex piece of machine
> learning software in 22 hours, compared to 3 months for the Java
> version?  Well, actually yes, I do, because that was 3 months of my
> life down the toilet for something that is too slow to be useful in Java.
>
>  
>
> Any argument depends on your priorities. I’ve written tons of web
> apps, because I needed to get paid.  I’ve written better shitty mobile
> apps than the average shitty mobile apps.  However, I’m not going to
> do any of that any longer in crap that never improves, because after
> 26 years the irritability it produces is more than it’s worth. 
>
>  
>
> A few weeks ago, a recruiter that specializes in Smalltalk called me
> about a job, although they were well aware I live 1500 miles away from
> the city I lived in when I had worked through them, to see if I’d be
> willing to move back there for a job.  That sounds like another ‘there
> aren’t enough Smalltalk developers”, but it wasn’t, because the job
> wasn’t writing Smalltalk.  It was writing Java.
>
>  
>
> The person hiring, though, wouldn’t look at anyone who didn’t write
> Smalltalk, because “people who grew up with Java don’t know how to
> write code”.  I don’t agree with that, I’ve known a (very few) good
> Java developers.  I would say, though, that I’ve known far more
> incompetent ones than good ones, and I can’t think of any incompetent
> Smalltalk developers off the top of my head. 
>
>  
>
> Nor have I ever heard a developer in Smalltalk, or Haskell, or LISP,
> or even C, complain about how hard maintaining state is or coming up
> with various hacks to avoid it, which seems to be the main point of
> every JavaScript based ‘technology’.  An application is by definition
> a state-machine, which implies plenty about JS developers on the whole.
>
>  
>
> If you’re a good developer you can write good code in (nearly)
> anything.  My question then is why would you want to write in crap?
>  The better question is why aren’t there more good developers in /any/
> language?
>
>  
>
> Every project I have been able to do in Smalltalk, though, has had one
> thing in common, the “shit has to work”.  Companies do use it, in fact
> I could name 4 large enterprises I’ve worked for who’ve written their
> own dialects, and they all use it only when “shit has to work”.  They
> know it’s more productive, they also know using it for more things
> would increase the availability of Smalltalk developers. 
>
>  
>
> Why do they not do it?  One reason, though it takes a while to
> recognize it, because management doesn’t admit even to themselves why
> they do it, or not very often.  

Re: [Pharo-users] Exchanging information between 2 pharo applications (2 images running on two different computers)

[Paulo R. Dellani]

well, I downloaded the .mcz package
<http://smalltalkhub.com/mc/panuw/zeromq/main/ZeroMQ-PanuWetterstrand.31.mcz>,
unzipped it and changed the
source code accordingly using a text editor (Smalltalkers can use
text editors to edit code too!). Later on I could successfully file-in
the file in a new Pharo 6 image. The code need more changes to work,
however. Lets see how long it takes to get a few ZeroMQ examples
running. I will publish my "fork".

Cheers,

Paulo

On 10/29/2017 03:09 PM, Paulo R. Dellani wrote:
> Dear all,
>
> I would like to give ZeroMQ a try in Smalltalk, but am unable to
> load it on a new image successfully. In Pharo 5, I loaded the package
> ConfigurationOfZeroMQ from therepository in smalltalkhub
> <http://smalltalkhub.com/#%21/%7Epanuw/zeromq> and
> evaluated the following to load the code:
>
> ConfigurationOfZeroMQ loadBleedingEdge
>
> It seems to load everything well, but when I try to look at the source
> code of the methods that call the C routines from libzmq using the
> system browser, the system exhibits the following error message:
>
> UndefinedObject(Object)>>doesNotUnderstand: #keywords
> RBFFICallPragma(RBPragmaNode)>>selectorParts
> RubSHTextStylerST80(SHRBTextStyler)>>visitPragmaNode:
> RBFFICallPragma(RBPragmaNode)>>acceptVisitor:
> RubSHTextStylerST80(SHRBTextStyler)>>visitNode:
> [ :each | self visitNode: each ] in
> RubSHTextStylerST80>>visitMethodNode: in Block: [ :each | self
> visitNode: each ]
> OrderedCollection>>do:
>
> (its a long stack, cutting here)
>
> When loading ZeroMQ on Pharo 6, a window pops-up with the title
> 'Syntax Error: Literal constant expected' showing the source code
> of a method defining a call to a routine from a C library:
>
> apiDeleteDC: aHDC
>      bool 'DeleteDC' (Win32HDC)
> module:'gdi32.dll'>
>     ^self externalCallFailed
>
> If I update the syntax, re-writing the code above as
>
> apiDeleteDC: aHDC
>     ^self ffiCall: #( bool DeleteDC (Win32HDC aHDC) ) module:'gdi32.dll'
>
> the compiler accepts it and the process can go on, but eventually
> the system will become unstable...
>
> Any ideas on how to solve this problems? Is this syntax still supported
> in Pharo5 & 6?
>
> Cheers,
>
> Paulo
>
> On 10/25/2017 03:47 PM, Sebastian Heidbrink via Pharo-users wrote:
>> ForwardedMessage.eml
>>
>> Subject:
>> Re: [Pharo-users] Exchanging information between 2 pharo applications
>> (2 images running on two different computers)
>> From:
>> Sebastian Heidbrink <shei...@yahoo.de>
>> Date:
>> 10/25/2017 03:47 PM
>>
>> To:
>> pharo-users@lists.pharo.org
>>
>>
>> Hi Cederik,
>>
>> you should have a look at http://smalltalkhub.com/#!/~panuw/zeromq
>> ZeroMQ is a networking library. Nice thing about it is that all the
>> networking related workload is dealt with in a second process. That
>> can save you some resources within Smalltalk.
>

Re: [Pharo-users] Smalltalk Argument

[Paulo R. Dellani]

On 10/20/2017 10:38 AM, Pavel Krivanek wrote:
>
>
> 2017-10-20 10:20 GMT+02:00 Marten Feldtmann  >:
>
> I do not want to spoil the party (perhaps I've done this already)
> - but
> has anyone done a serious inspection of this number: 67%.
>
> They have interviewed 64000 persons and 67% of the people should
> "love"
> Smalltalk? Come on, that seems to be not possible. Perhaps 67% of the
> user already using Smalltalk "love" that.
>
>
> As far as I understand it, the question was different. They asked, if
> you use Smalltalk, would you like to use it the next year too (or
> something like that). Then the number makes more sense.
>

You are right, look at the legend of the graphic:

"% of developers who are developing with the language
or technology and have expressed interest in continuing
to develop with it"

Cheers, Paulo

Re: [Pharo-users] Smalltalk Argument

[Paulo R. Dellani]

I think you have nailed it, Joachim!

The development environment is per se very productive and easy to use
and learn
but at the moment you need something that isn't present in your code
library,
things can get very hard. Well, that's not really new and not only a
problem
that concerns Smalltalk, but with the greater number of developers in
other languages
chances are that someone already wrote some code concerning your needs.

Well I will go back to my coding here now ;-)

Cheers,

Paulo

On 10/20/2017 09:23 AM, jtuc...@objektfabrik.de wrote:
> First of all: I'd say the question itself is not a question but an
> excuse. I am not arguing there are enough Smalltalkers or cheap ones.
> But I think the question is just a way of saying "we don't want to do
> it for reasons that we ourselves cannot really express". If you are a
> good developer, learning Smalltalk is easy. If you are a good
> developer you've heard the sentence "we've taken the goos parts from
> x,y,z and Smalltalk" at least twice a year. So you most likely would
> like to learn it anyways.
>
> A shortage of developers doesn't exist. What exists is an
> unwillingness of companies to get people trained in a technology. If
> Smalltalk was cool and great in their opinion, they wouldn't care.
> It's that simple. As a consultant, I've heard that argument so often.
> Not ferom Startups, but from insurance companies, Banks or Car
> manufacturers who spend millions on useless, endless meetings and
> stuff instead of just hiring somebody to teach a couple of developers
> Smalltalk. It's just a lie: the shortage of Smalltalk developers is
> not a problem.
>
> And, to be honest: what is it we actually are better in by using
> Smalltalk?
> Can we build cool looking web apps in extremely short time? No.
> Can we build mobile Apps with little effort? No.
> Does our Smalltalk ship lots of great libraries for all kinds of
> things that are not availabel in similar quality in any other language?
> Are we lying when we say we are so extremely over-productive as
> compared to other languages?
>
> I know, all that live debugging stuff and such is great and it is much
> faster to find & fix a bug in Smalltalk than in any other environment
> I've used so far. But that is really only true for business code. When
> I need to connect to things or want to build a modern GUI or a web
> application with a great look, I am nowhere near productive,
> because I simply have to build my own stuff or learn how to use other
> external resources. If I want to build something for a mobile device,
> I will only hear that somebody somewhere has done it before. No docs,
> no proof, no ready-made tool for me.
>
>
> Shortage of developers is not really the problem. If Smalltalk was as
> cool as we like to make ourselves believe, this problem would be
> non-existent. If somebody took out their iPad and told an audience:
> "We did this in Smalltalk in 40% of the time it would have taken in
> Swift", and if that something was a must-have for people, things would
> be much easier. But nobody has.
>
>
> I am absolutely over-exaggerating, because I make my living with an
> SaaS product written in Smalltalk (not Pharo). I have lots of fun with
> Smalltalk and - as you - am convince that many parts of what we've
> done so far would've taken much longer or even be impossible in other
> languages. But the advantage was eaten by our extremely steep learning
> curve for web technologies and for building something that works
> almost as well as tools like Angular or jQuery Mobile.
>
> Smalltalk is cool, and the day somebody shows me something like
> Google's flutter in Smalltalk, I am ready to bet a lot on a bright
> future for Smalltalk. But until then, I'd say these arguments about
> productivity are just us trying to make ourselves believe we're still
> the top of the food chain. We've done that for almost thirty years now
> and still aren't ready to stop it. But we've been lying to ourselves
> and still do so.
>
> I don't think there is a point in discussing about the usefulness of a
> language using an argument like the number or ready-made developers.
> That is just an argument they know you can't win. The real question is
> and should be: what is the benefit of using Smalltalk. Our
> productivity argument is a lie as soon as we have to build something
> that uses or runs on technology that has been invented after 1990.
>
>
> Okay, shoot ;-)
>
> Joachim
>
>

Re: [Pharo-users] Smalltalk Argument

[Paulo R. Dellani]

Dear Ben, Jimmie, Stephane, Tim, Dimitris, Marten, Davorin, Stephan,
Sebastian and James,

thank you for your feedback! Your excellent replies will sure help me with
my "Smalltalk Argument". Obviously the language cannot be employed to
efficiently implement solutions for problems in all domains, but it cannot
simply be ruled out just because it is not so visible as other languages
clamoring for the spotlight, as Jimmie pointed out.

So far I got good results that can talk for themselves thanks to
Pharo/Smalltalk.
So the problem here, I believe, is really Smalltalk not being the "cool
kid in town",
which leads to a misperception of the language by the non-versed. This
can be
certainly be blamed to the lack of a good business oriented OSS
Smalltalk years ago,
as Ben guessed, but certainly there are other factors, which are not the
scope
of this discussion.

The fact that a good OO-software developer can learn and start to get
productive
in Smalltalk in a relatively short amount of time, as pointed out by
several of you,
will make a good argument against the concerns of my colleagues here, which
are mainly non-software developers. And surely the willingness to learn
a new
language is a sign to be looked at in a candidate, as pointed by you too.

The second most loved language by 67% of developers surveyed cannot simply
be ruled out because of unfounded concerns. (Thanks again for the
information,
Jimmie). I think there is really a great potential here, and surely
there is a greater
pool of developer candidates to "draw from" than one can initially
imagine/see.

Cheers,

Paulo

On 10/20/2017 12:17 AM, Ben Coman wrote:
>
>
> On Thu, Oct 19, 2017 at 3:04 PM, Paulo R. Dellani <dell...@pobox.com
> <mailto:dell...@pobox.com>> wrote:
>
> Dear all,
>
> after using Smalltalk for several years I developed a passion for the
> language (how not to?), and Pharo is just so great to develop with.
> So thank you guys for keeping this wonderful project running.
>
> Unfortunately, it is not easy to always point out why Smalltalk
> should be employed as "main development language" in a team
> or for a project. In the last discussion of this sort I was confronted
> with the question "where are we going to get new smalltalk
> developers if our startup grows or if you go?". Well, I had no
> good answer to that. What would have you answered?
>
> Cheers,
>
> Paulo
>
>
>
> When Smalltalk comes up on reddit, news.ycombinator, etc,
> I often see comments "Used Smalltalk 10 years ago, loved it, but not
> in my day job for years ..."
> The guess the lack of a good business oriented OSS Smalltalk years ago
> may be to blame.
> Only supposition, but with the long history of Smalltalker, the pool
> to draw from may be greater than first apparent.
> The main problem may be that these people are not searching for
> Smalltalk jobs due to the perceived availability of jobs.
>
>
> There would obviously be some lag, but for longer term planning, talk
> to your local education providers about introducing Smalltalk as the
> "best" environment for teaching OO,
> and then take the talented students from there.  Consider contacting
> the academic partners here...
> http://consortium.pharo.org/
>
>
> Another approach depending on the project structure might be to "just"
> prototype in Smalltalk (because its highly productive to explore a
> domain with its built in data persistence)
> and per Fred Brooks plan to throw it away to cleanly implement in a
> mainstream language once you "know" what needs to be done.  
> I remember seeing one case reported here that the prototype worked so
> well that the client didn't bother with the second step.
>
>
> cheers -ben

Re: [Pharo-users] Smalltalk Argument

[Paulo R. Dellani]

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  <%22mailto:he...@callistohouse.club%22>> 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  <%22%22mailto:he...@callistohouse.club%22%22>> 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: he...@callistohouse.club
> To: p...@highoctane.be , Any question
> about pharo is welcome 
>
> 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, p...@highoctane.be
>  <%22%22%22mailto:p...@highoctane.be%22%22%22>> 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/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing
> 
> <%22%22%22https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPjUQNIyA6tmuxyZz1UaX5ikEU/edit?usp=sharing%22%22%22>
>
>
> 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
> 
> <%22%22%22https://github.com/strophe/libstrophe/blob/master/src/tls_openssl.c%22%22%22>
>
>
> 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
>  <%22%22%22mailto:he...@callistohouse.club%22%22%22>>
> 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
>