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

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

by 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, tesonep(a)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.Â > > 0xFFFFFFFF is a valid positive for a long, but a -1 for an int.Â > > Cheers. > > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

Oct. 30, 2017

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

by tesonep＠gmail.com

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. 0xFFFFFFFF is a valid positive for a long, but a -1 for an int. Cheers. On Mon, Oct 30, 2017 at 4:26 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Ah ok I know that one, just did not know it was named "two's complement" , > looks to me normal error. I have seen this value many times in case of > errors while debugging C code with GBP > > It returns error probably because of the reason I outlined in my previous > reply. > > On Mon, Oct 30, 2017 at 3:51 PM Paulo R. Dellani <dellani(a)pobox.com> > wrote: > >> "Two`s complement" is one possible way to represent signed integers in >> binary form (1). >> >> When the message apiZmqMsgRecv: message socket: socket withFlags: flags is >> 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 0xFFFFFFFF, >> 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 <dellani(a)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 >>> >> >> -- Pablo Tesone. tesonep(a)gmail.com

Oct. 30, 2017

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

by Dimitris Chloupis

Ah ok I know that one, just did not know it was named "two's complement" , looks to me normal error. I have seen this value many times in case of errors while debugging C code with GBP It returns error probably because of the reason I outlined in my previous reply. On Mon, Oct 30, 2017 at 3:51 PM Paulo R. Dellani <dellani(a)pobox.com> wrote: > "Two`s complement" is one possible way to represent signed integers in > binary form (1). > > When the message apiZmqMsgRecv: message socket: socket withFlags: flags is > 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 0xFFFFFFFF, > 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 <dellani(a)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 >> > >

Oct. 30, 2017

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

by 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 0xFFFFFFFF, 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 <dellani(a)pobox.com > <mailto:dellani@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 >

Oct. 30, 2017

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

by Dimitris Chloupis

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 <dellani(a)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 >

Oct. 30, 2017

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

by 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

Oct. 30, 2017

Return value of a FFI call to a external function is its 2`s complement

by Paulo R. Dellani

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

Oct. 30, 2017

Re: [Pharo-users] The start of this article is a problem for me. I hope this can be re-thought.

by David Mason

Hear! Hear! To be fair, the person who wrote the article has no direct role in the Amber team (or Pharo, or PharoJS), he is simply a Smalltalk fan who is trying to help build the community. But you make an excellent point.! On 29 October 2017 at 17:17, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: > https://medium.com/smalltalk-talk/a-gentle-introduction-to- > amber-8c532631e9ab > > > > Smalltalk is a programming language/environment etc. Physical > attractiveness of people doesn't really affect anything we're doing here. > And using it for marketing is offensive a significant number of people. > I'm hopeful we can do better as a community. >

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by Offray Vladimir Luna CÃ¡rdenas

Read the User Manual [1] to install it and learn the basics of its workings. Once you have created your first document or hit the first bump, ask on this list. I will be around ;-). [1] http://mutabit.com/repos.fossil/grafoscopio/doc/tip/Docs/En/Books/Manual/ma… Cheers, Offray On 29/10/17 17:00, henry wrote: > How could I get started documenting my components with Grafoscopio? I > am interested in learning. > > I just got ASN.1 lengths right, in Java. I am looking to Pharo and > Java with an encrypted connection between them. > > > - HH > > > On Sun, Oct 29, 2017 at 16:59, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <%22mailto:offray.luna@mutabit.com%22>> wrote: > > Well is more "build and they will come, if you build also a > community who will come", which is hard, but data storytelling and > visualization as filed and dynamic moldable tools give us a > advantage point to tackle such hard problems. > > Cheers, > > Offray > > > On 29/10/17 13:13, henry wrote: > > I have heard this summarized by the term: "build it and they > will come". I think the data visualization aspect is where > Pharo entering BigData space could really payoff. That comes > down to data manipulation. Can Pharo read Avro? > > - HH > > > On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com > <%22mailto:offray.luna@mutabit.com%22>> wrote: > > Thanks a lot Paulo for starting this thread and all the > participants for the clever and enlightening answers. I > just want to add my two cents. On 26/10/17 07:53, Dimitris > Chloupis wrote: > > My personal opinion is that as > pessimistic it may sound, Smalltalk has > very little to > offer in the library front. The language is still > > stellar and live environment is a great concept but from > there on > there is a decline. Sure if your are low demand > kind of person on the > library front and dont mind > implementing stuff by yourself you wont > mind the lack of > libraries but most coders , me included , dont have > this > luxury. Especially making a living with a language is a > > completely different story from learning it as a hobby,Â > > > I think and thatâs a personal opinion, that Smalltalk > goes the wrong > direction. It tries to be a do it all > language, but we already have an > army of do it all > languages. I think it would excel as the backbone in > big > complex projects. Like the Moose project is doing with > code > analysis and visualization. I think this is an > excellent direction to > go with Smalltalk. Reflection is > the big strength of Smalltalk the > ability to communicate > with its code in a direct matter. So I think > that a > Smalltalk implementation that can analyze and visualize > code > written in other languages would have been a pretty > serious reason for > people to learn Smalltalk.Â > > I am > very happy to see Pharo go towards that direction and yes > I would > definitely recommend it without hesitationÂ for > code analysis and > project management tool. Its no > coincidence that we have seen a > serious growth in our > community. When I joined back in 2011 we all > were > posting at pharo-dev, pharo-users was a dead zone and then > the > community grow larger and larger we soon may need a > third mailing list.Â > > Code complexity is an issues for > all large projects and tools that > help manage this > without having to convert to another language are > very > popular. About findingÂ niche where you can learn Pharo > and make a living from it, I think that I may be behind a > sweet spot in the field of reproducible research and data > storytelling and visualization, for different fields like > activism, journalism, science and engineering. Iâm > "working in my PhD", so I donât get paid for using Pharo & > friends (well if fact Iâm in a loan to finish my PhD), but > using Pharo have allowed my to get more dynamic results > that with previous technologies (mostly Python and Web > ones). By being able to prototype quickly I have improved > my research experience and results, which is a way to > improve research (self) funding. Also, activists, > journalist, researchers and other novices interested in > data storytelling and visualization, care little about > popularity of the language or being able to make apps > (mobile or web). What they care is about being able to > tell the story and Pharo, agile visualization and moldable > tools, have a lot to offer in this front. Theyâre easy to > learn and to adapt to fit the needs of the problems behind > those stories, as we have done with Grafoscopio[1]. So, is > nice to be part of a "trend", (data science, reproducible > research, data storytelling and data visualization) but > not being part of one that doesnât give you the freedom to > use tools that matter to you, because of the ideas they > embody and the added value they create for you and your > community. [1] > http://mutabit.com/grafoscopio/index.en.html Also, being > in Latin America, means that we can bootstrap ourselves > into alternative futures by using alternative (digital) > infrastructures and tools, without to much worry about the > deep investments in money and/or expertise on > bloated/popular technologies (we donât have such > investments here!). We can learn from the experience of > the "Global North", without following that path, but by > taking a critical approach to it (for example regarding > overcomplex, non-dynamic, bloated technologies). On the > community front, I think is important to do something to > break the circular logic of popularity: Smalltalk is > unpopular, so we donât get developers, so we donât have > libraries, and this makes such tech unpopular. Weâre a > nascent community of data storytellers and activists > learning how to use Pharo to tell our voices and how to > modify the tools to tell them in more potent/fluid ways. > We have done this mostly by ourselves, without any support > from industry or government and mostly none from academy. > Despite of the fragility of our hackerspace[2], this has > been done in a consistent way since almost two years[3] (I > started to learn Pharo, in a sparse way, 3 years ago). So, > there are ways to break the circular logic and bootstrap > communities around the advantages of the Pharo/Smalltalk > environment in places where it can be aligned to the > trends but also take a critical approach to them by > providing added value. [2] http://hackbo.co/ [3] > http://mutabit.com/dataweek/ So finding a niche and > bootstrapping tools and communities in it, seems a way to > deploy the Smalltalk Argument by example into the world, > which is a pretty powerful way to argument against > skeptics. Cheers, Offray > >

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

Interesting. Very. Thank you. - HH On Sun, Oct 29, 2017 at 17:17, phil(a)highoctane.be <[phil(a)highoctane.be]("mailto:phil@highoctane.be")> wrote: > Pharo can read Avro when this will be UFFI'ed > > [https://avro.apache.org/docs/1.7.3/api/c/index.html]("https://avro.apache.org/docs/1.7.3/api/c/index.html") > > But that is eminently doable. > > Phiil > > On Sun, Oct 29, 2017 at 7:13 PM, henry <[henry(a)callistohouse.club]("mailto:henry@callistohouse.club")> wrote: > >> I have heard this summarized by the term: "build it and they will come". I think the data visualization aspect is where Pharo entering BigData space could really payoff. That comes down to data manipulation. Can Pharo read Avro? >> >> - HH >> >> On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas <[offray.luna(a)mutabit.com]("mailto:offray.luna@mutabit.com")> wrote: >> >>> Thanks a lot Paulo for starting this thread and all the participants for the clever and enlightening answers. I just want to add my two cents. On 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as pessimistic it may sound, Smalltalk has > very little to offer in the library front. The language is still > stellar and live environment is a great concept but from there on > there is a decline. Sure if your are low demand kind of person on the > library front and dont mind implementing stuff by yourself you wont > mind the lack of libraries but most coders , me included , dont have > this luxury. Especially making a living with a language is a > completely different story from learning it as a hobby, > > I think and that's a personal opinion, that Smalltalk goes the wrong > direction. It tries to be a do it all language, but we already have an > army of do it all languages. I think it would excel as the backbone in > big complex projects. Like the Moose project is doing with code > analysis and visualization. I think this is an excellent direction to > go with Smalltalk. Reflection is the big strength of Smalltalk the > ability to communicate with its code in a direct matter. So I think > that a Smalltalk implementation that can analyze and visualize code > written in other languages would have been a pretty serious reason for > people to learn Smalltalk. > > I am very happy to see Pharo go towards that direction and yes I would > definitely recommend it without hesitation for code analysis and > project management tool. Its no coincidence that we have seen a > serious growth in our community. When I joined back in 2011 we all > were posting at pharo-dev, pharo-users was a dead zone and then the > community grow larger and larger we soon may need a third mailing list. > > Code complexity is an issues for all large projects and tools that > help manage this without having to convert to another language are > very popular. About finding niche where you can learn Pharo and make a living from it, I think that I may be behind a sweet spot in the field of reproducible research and data storytelling and visualization, for different fields like activism, journalism, science and engineering. I'm "working in my PhD", so I don't get paid for using Pharo & friends (well if fact I'm in a loan to finish my PhD), but using Pharo have allowed my to get more dynamic results that with previous technologies (mostly Python and Web ones). By being able to prototype quickly I have improved my research experience and results, which is a way to improve research (self) funding. Also, activists, journalist, researchers and other novices interested in data storytelling and visualization, care little about popularity of the language or being able to make apps (mobile or web). What they care is about being able to tell the story and Pharo, agile visualization and moldable tools, have a lot to offer in this front. They're easy to learn and to adapt to fit the needs of the problems behind those stories, as we have done with Grafoscopio[1]. So, is nice to be part of a "trend", (data science, reproducible research, data storytelling and data visualization) but not being part of one that doesn't give you the freedom to use tools that matter to you, because of the ideas they embody and the added value they create for you and your community. [1] [http://mutabit.com/grafoscopio/index.en.html]("http://mutabit.com/grafoscopio/index.en.html") Also, being in Latin America, means that we can bootstrap ourselves into alternative futures by using alternative (digital) infrastructures and tools, without to much worry about the deep investments in money and/or expertise on bloated/popular technologies (we don't have such investments here!). We can learn from the experience of the "Global North", without following that path, but by taking a critical approach to it (for example regarding overcomplex, non-dynamic, bloated technologies). On the community front, I think is important to do something to break the circular logic of popularity: Smalltalk is unpopular, so we don't get developers, so we don't have libraries, and this makes such tech unpopular. We're a nascent community of data storytellers and activists learning how to use Pharo to tell our voices and how to modify the tools to tell them in more potent/fluid ways. We have done this mostly by ourselves, without any support from industry or government and mostly none from academy. Despite of the fragility of our hackerspace[2], this has been done in a consistent way since almost two years[3] (I started to learn Pharo, in a sparse way, 3 years ago). So, there are ways to break the circular logic and bootstrap communities around the advantages of the Pharo/Smalltalk environment in places where it can be aligned to the trends but also take a critical approach to them by providing added value. [2] [http://hackbo.co/]("http://hackbo.co/") [3] [http://mutabit.com/dataweek/]("http://mutabit.com/dataweek/")So finding a niche and bootstrapping tools and communities in it, seems a way to deploy the Smalltalk Argument by example into the world, which is a pretty powerful way to argument against skeptics. Cheers, Offray

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

How could I get started documenting my components with Grafoscopio? I am interested in learning. I just got ASN.1 lengths right, in Java. I am looking to Pharo and Java with an encrypted connection between them. - HH On Sun, Oct 29, 2017 at 16:59, Offray Vladimir Luna CÃ¡rdenas <[offray.luna(a)mutabit.com]("mailto:offray.luna@mutabit.com")> wrote: > Well is more "build and they will come, if you build also a community who will come", which is hard, but data storytelling and visualization as filed and dynamic moldable tools give us a advantage point to tackle such hard problems. > > Cheers, > > Offray > > On 29/10/17 13:13, henry wrote: > >> I have heard this summarized by the term: "build it and they will come". I think the data visualization aspect is where Pharo entering BigData space could really payoff. That comes down to data manipulation. Can Pharo read Avro? >> >> - HH >> >> On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas < [offray.luna(a)mutabit.com]("mailto:offray.luna@mutabit.com")> wrote: >> >>> Thanks a lot Paulo for starting this thread and all the participants for the clever and enlightening answers. I just want to add my two cents. On 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as pessimistic it may sound, Smalltalk has > very little to offer in the library front. The language is still > stellar and live environment is a great concept but from there on > there is a decline. Sure if your are low demand kind of person on the > library front and dont mind implementing stuff by yourself you wont > mind the lack of libraries but most coders , me included , dont have > this luxury. Especially making a living with a language is a > completely different story from learning it as a hobby, > > I think and thatâs a personal opinion, that Smalltalk goes the wrong > direction. It tries to be a do it all language, but we already have an > army of do it all languages. I think it would excel as the backbone in > big complex projects. Like the Moose project is doing with code > analysis and visualization. I think this is an excellent direction to > go with Smalltalk. Reflection is the big strength of Smalltalk the > ability to communicate with its code in a direct matter. So I think > that a Smalltalk implementation that can analyze and visualize code > written in other languages would have been a pretty serious reason for > people to learn Smalltalk. > > I am very happy to see Pharo go towards that direction and yes I would > definitely recommend it without hesitation for code analysis and > project management tool. Its no coincidence that we have seen a > serious growth in our community. When I joined back in 2011 we all > were posting at pharo-dev, pharo-users was a dead zone and then the > community grow larger and larger we soon may need a third mailing list. > > Code complexity is an issues for all large projects and tools that > help manage this without having to convert to another language are > very popular. About finding niche where you can learn Pharo and make a living from it, I think that I may be behind a sweet spot in the field of reproducible research and data storytelling and visualization, for different fields like activism, journalism, science and engineering. Iâm "working in my PhD", so I donât get paid for using Pharo & friends (well if fact Iâm in a loan to finish my PhD), but using Pharo have allowed my to get more dynamic results that with previous technologies (mostly Python and Web ones). By being able to prototype quickly I have improved my research experience and results, which is a way to improve research (self) funding. Also, activists, journalist, researchers and other novices interested in data storytelling and visualization, care little about popularity of the language or being able to make apps (mobile or web). What they care is about being able to tell the story and Pharo, agile visualization and moldable tools, have a lot to offer in this front. Theyâre easy to learn and to adapt to fit the needs of the problems behind those stories, as we have done with Grafoscopio[1]. So, is nice to be part of a "trend", (data science, reproducible research, data storytelling and data visualization) but not being part of one that doesnât give you the freedom to use tools that matter to you, because of the ideas they embody and the added value they create for you and your community. [1] [http://mutabit.com/grafoscopio/index.en.html]("http://mutabit.com/grafoscopio/index.en.html") Also, being in Latin America, means that we can bootstrap ourselves into alternative futures by using alternative (digital) infrastructures and tools, without to much worry about the deep investments in money and/or expertise on bloated/popular technologies (we donât have such investments here!). We can learn from the experience of the "Global North", without following that path, but by taking a critical approach to it (for example regarding overcomplex, non-dynamic, bloated technologies). On the community front, I think is important to do something to break the circular logic of popularity: Smalltalk is unpopular, so we donât get developers, so we donât have libraries, and this makes such tech unpopular. Weâre a nascent community of data storytellers and activists learning how to use Pharo to tell our voices and how to modify the tools to tell them in more potent/fluid ways. We have done this mostly by ourselves, without any support from industry or government and mostly none from academy. Despite of the fragility of our hackerspace[2], this has been done in a consistent way since almost two years[3] (I started to learn Pharo, in a sparse way, 3 years ago). So, there are ways to break the circular logic and bootstrap communities around the advantages of the Pharo/Smalltalk environment in places where it can be aligned to the trends but also take a critical approach to them by providing added value. [2] [http://hackbo.co/]("http://hackbo.co/") [3] [http://mutabit.com/dataweek/]("http://mutabit.com/dataweek/") So finding a niche and bootstrapping tools and communities in it, seems a way to deploy the Smalltalk Argument by example into the world, which is a pretty powerful way to argument against skeptics. Cheers, Offray

Oct. 29, 2017

The start of this article is a problem for me. I hope this can be re-thought.

by PAUL DEBRUICKER

https://medium.com/smalltalk-talk/a-gentle-introduction-to-amber-8c532631e9… Smalltalk is a programming language/environment etc. Physical attractiveness of people doesn't really affect anything we're doing here. And using it for marketing is offensive a significant number of people. I'm hopeful we can do better as a community.

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by phil＠highoctane.be

Pharo can read Avro when this will be UFFI'ed https://avro.apache.org/docs/1.7.3/api/c/index.html But that is eminently doable. Phiil On Sun, Oct 29, 2017 at 7:13 PM, henry <henry(a)callistohouse.club> wrote: > I have heard this summarized by the term: "build it and they will come". I > think the data visualization aspect is where Pharo entering BigData space > could really payoff. That comes down to data manipulation. Can Pharo read > Avro? > > - HH > > > On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas < > offray.luna(a)mutabit.com> wrote: > > Thanks a lot Paulo for starting this thread and all the participants for > the clever and enlightening answers. I just want to add my two cents. On > 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as > pessimistic it may sound, Smalltalk has > very little to offer in the > library front. The language is still > stellar and live environment is a > great concept but from there on > there is a decline. Sure if your are low > demand kind of person on the > library front and dont mind implementing > stuff by yourself you wont > mind the lack of libraries but most coders , > me included , dont have > this luxury. Especially making a living with a > language is a > completely different story from learning it as a hobby, > > > I think and that's a personal opinion, that Smalltalk goes the wrong > > direction. It tries to be a do it all language, but we already have an > > army of do it all languages. I think it would excel as the backbone in > > big complex projects. Like the Moose project is doing with code > analysis > and visualization. I think this is an excellent direction to > go with > Smalltalk. Reflection is the big strength of Smalltalk the > ability to > communicate with its code in a direct matter. So I think > that a Smalltalk > implementation that can analyze and visualize code > written in other > languages would have been a pretty serious reason for > people to learn > Smalltalk. > > I am very happy to see Pharo go towards that direction and > yes I would > definitely recommend it without hesitation for code analysis > and > project management tool. Its no coincidence that we have seen a > > serious growth in our community. When I joined back in 2011 we all > were > posting at pharo-dev, pharo-users was a dead zone and then the > community > grow larger and larger we soon may need a third mailing list. > > Code > complexity is an issues for all large projects and tools that > help manage > this without having to convert to another language are > very popular. > About finding niche where you can learn Pharo and make a living from it, I > think that I may be behind a sweet spot in the field of reproducible > research and data storytelling and visualization, for different fields like > activism, journalism, science and engineering. I'm "working in my PhD", so > I don't get paid for using Pharo & friends (well if fact I'm in a loan to > finish my PhD), but using Pharo have allowed my to get more dynamic results > that with previous technologies (mostly Python and Web ones). By being able > to prototype quickly I have improved my research experience and results, > which is a way to improve research (self) funding. Also, activists, > journalist, researchers and other novices interested in data storytelling > and visualization, care little about popularity of the language or being > able to make apps (mobile or web). What they care is about being able to > tell the story and Pharo, agile visualization and moldable tools, have a > lot to offer in this front. They're easy to learn and to adapt to fit the > needs of the problems behind those stories, as we have done with > Grafoscopio[1]. So, is nice to be part of a "trend", (data science, > reproducible research, data storytelling and data visualization) but not > being part of one that doesn't give you the freedom to use tools that > matter to you, because of the ideas they embody and the added value they > create for you and your community. [1] http://mutabit.com/ > grafoscopio/index.en.html Also, being in Latin America, means that we can > bootstrap ourselves into alternative futures by using alternative (digital) > infrastructures and tools, without to much worry about the deep investments > in money and/or expertise on bloated/popular technologies (we don't have > such investments here!). We can learn from the experience of the "Global > North", without following that path, but by taking a critical approach to > it (for example regarding overcomplex, non-dynamic, bloated technologies). > On the community front, I think is important to do something to break the > circular logic of popularity: Smalltalk is unpopular, so we don't get > developers, so we don't have libraries, and this makes such tech unpopular. > We're a nascent community of data storytellers and activists learning how > to use Pharo to tell our voices and how to modify the tools to tell them in > more potent/fluid ways. We have done this mostly by ourselves, without any > support from industry or government and mostly none from academy. Despite > of the fragility of our hackerspace[2], this has been done in a consistent > way since almost two years[3] (I started to learn Pharo, in a sparse way, 3 > years ago). So, there are ways to break the circular logic and bootstrap > communities around the advantages of the Pharo/Smalltalk environment in > places where it can be aligned to the trends but also take a critical > approach to them by providing added value. [2] http://hackbo.co/ [3] > http://mutabit.com/dataweek/ So finding a niche and bootstrapping tools > and communities in it, seems a way to deploy the Smalltalk Argument by > example into the world, which is a pretty powerful way to argument against > skeptics. Cheers, Offray > >

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by Offray Vladimir Luna CÃ¡rdenas

Well is more "build and they will come, if you build also a community who will come", which is hard, but data storytelling and visualization as filed and dynamic moldable tools give us a advantage point to tackle such hard problems. Cheers, Offray On 29/10/17 13:13, henry wrote: > I have heard this summarized by the term: "build it and they will > come". I think the data visualization aspect is where Pharo entering > BigData space could really payoff. That comes down to data > manipulation. Can Pharo read Avro? > > - HH > > > On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >> Thanks a lot Paulo for starting this thread and all the participants >> for the clever and enlightening answers. I just want to add my two >> cents. On 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal >> opinion is that as pessimistic it may sound, Smalltalk has > very >> little to offer in the library front. The language is still > stellar >> and live environment is a great concept but from there on > there is >> a decline. Sure if your are low demand kind of person on the > >> library front and dont mind implementing stuff by yourself you wont > >> mind the lack of libraries but most coders , me included , dont have >> > this luxury. Especially making a living with a language is a > >> completely different story from learning it as a hobby,Â > > I think >> and that's a personal opinion, that Smalltalk goes the wrong > >> direction. It tries to be a do it all language, but we already have >> an > army of do it all languages. I think it would excel as the >> backbone in > big complex projects. Like the Moose project is doing >> with code > analysis and visualization. I think this is an excellent >> direction to > go with Smalltalk. Reflection is the big strength of >> Smalltalk the > ability to communicate with its code in a direct >> matter. So I think > that a Smalltalk implementation that can analyze >> and visualize code > written in other languages would have been a >> pretty serious reason for > people to learn Smalltalk.Â > > I am very >> happy to see Pharo go towards that direction and yes I would > >> definitely recommend it without hesitationÂ for code analysis and > >> project management tool. Its no coincidence that we have seen a > >> serious growth in our community. When I joined back in 2011 we all > >> were posting at pharo-dev, pharo-users was a dead zone and then the > >> community grow larger and larger we soon may need a third mailing >> list.Â > > Code complexity is an issues for all large projects and >> tools that > help manage this without having to convert to another >> language are > very popular. About findingÂ niche where you can learn >> Pharo and make a living from it, I think that I may be behind a sweet >> spot in the field of reproducible research and data storytelling and >> visualization, for different fields like activism, journalism, >> science and engineering. I'm "working in my PhD", so I don't get paid >> for using Pharo & friends (well if fact I'm in a loan to finish my >> PhD), but using Pharo have allowed my to get more dynamic results >> that with previous technologies (mostly Python and Web ones). By >> being able to prototype quickly I have improved my research >> experience and results, which is a way to improve research (self) >> funding. Also, activists, journalist, researchers and other novices >> interested in data storytelling and visualization, care little about >> popularity of the language or being able to make apps (mobile or >> web). What they care is about being able to tell the story and Pharo, >> agile visualization and moldable tools, have a lot to offer in this >> front. They're easy to learn and to adapt to fit the needs of the >> problems behind those stories, as we have done with Grafoscopio[1]. >> So, is nice to be part of a "trend", (data science, reproducible >> research, data storytelling and data visualization) but not being >> part of one that doesn't give you the freedom to use tools that >> matter to you, because of the ideas they embody and the added value >> they create for you and your community. [1] >> http://mutabit.com/grafoscopio/index.en.html Also, being in Latin >> America, means that we can bootstrap ourselves into alternative >> futures by using alternative (digital) infrastructures and tools, >> without to much worry about the deep investments in money and/or >> expertise on bloated/popular technologies (we don't have such >> investments here!). We can learn from the experience of the "Global >> North", without following that path, but by taking a critical >> approach to it (for example regarding overcomplex, non-dynamic, >> bloated technologies). On the community front, I think is important >> to do something to break the circular logic of popularity: Smalltalk >> is unpopular, so we don't get developers, so we don't have libraries, >> and this makes such tech unpopular. We're a nascent community of data >> storytellers and activists learning how to use Pharo to tell our >> voices and how to modify the tools to tell them in more potent/fluid >> ways. We have done this mostly by ourselves, without any support from >> industry or government and mostly none from academy. Despite of the >> fragility of our hackerspace[2], this has been done in a consistent >> way since almost two years[3] (I started to learn Pharo, in a sparse >> way, 3 years ago). So, there are ways to break the circular logic and >> bootstrap communities around the advantages of the Pharo/Smalltalk >> environment in places where it can be aligned to the trends but also >> take a critical approach to them by providing added value. [2] >> http://hackbo.co/ [3] http://mutabit.com/dataweek/ So finding a niche >> and bootstrapping tools and communities in it, seems a way to deploy >> the Smalltalk Argument by example into the world, which is a pretty >> powerful way to argument against skeptics. Cheers, Offray

Oct. 29, 2017

New Pharo Booklet

by Stephane Ducasse

Hi guys I just published a new little booklet on Pharo tips and tricks! Available at: http://books.pharo.org Feedback and contributions are welcome as usual. Stef

Oct. 29, 2017

Re: [Pharo-users] [GT] moldable tools for non-developers

by Offray Vladimir Luna CÃ¡rdenas

Hi Stef, Is kind of strange, but I didn't use Polymath at all for my prototypes on medicine data visualization[1] Panama Papers[2] or Twitter Data Selfies[3] or the book on Data Driven Journalism[4]. I just use Roassal, UDBC with Sqlite, NeoJSON and STON. So it may sound strange, but I think that Pharo is already a pretty good contestant on the area of Data Driven Storytelling, if we provide a more integrated "end user" experience (that's what I'm trying to do with Grafoscopio). Things like a better support for Markup languages with syntax highlighting and orthographic corrector (via GT-Documenter?), better GUI for querying data in SQL, are a felt needs and also integration with R has been asked.Â [1] http://mutabit.com/offray/blog/en/entry/sdv-infomed [2] http://mutabit.com/offray/blog/en/entry/panama-papers-1 [3] http://mutabit.com/offray/blog/en/entry/ds-twitter-mockup [4] http://mutabit.com/repos.fossil/mapeda/ That being said, I think that if we have something like Polymath integration and Math rendering inside Pharo, something like a Mathematica/Jupyter/TeXmacs notebook can be just around the corner, with a pretty superior DOM (live objects all the way down) and environment. I think that we could have a killer app for a growing niche! The main issue now is to provide researchers and data driven storytellers with a mature enough default experience to make them to bet on that Pharo powered vision of the future. Cheers, Offray On 29/10/17 15:26, Stephane Ducasse wrote: > Hi offray > > What I would like to know is what are the kind of mathematical support you need > for your data analyses and that is not support by polymath. > > I'm "working" (well sweet dream) on future book on collective > intelligence, basic AI stuff > and I think that roassal is cool but you need to have also filtering > and empowering the data. > > So what did you miss? > I want powerful data journalists (they are important for our world). > > > Stef > > On Fri, Oct 27, 2017 at 8:38 PM, Offray Vladimir Luna CÃ¡rdenas > <offray.luna(a)mutabit.com> wrote: >> Hi Sebastian, >> >> >> On 27/10/17 13:15, Sebastian Heidbrink via Pharo-users wrote: >>> that is kind of what I am looking for. Would you mind if I contacted >>> you directly? >>> I am in the process of formulizing a master thesis and would love to >>> bring Pharo into the mix. >>> >> No problem. Contact me. This weekend is a little bit busy with some >> deadlines I need to reach, but next week is fine. >> >>> Is you phd thesis public? >> It is at [1], with a public repository of the research artifacts since >> 2011 (before open research was in fashion :-P), but it is in Spanish. >> Sorry. I didn't have the time to clarify my mind about this research and >> also improve my English. But I would be glad to discuss it in English >> with you or anyone interested. You're very welcomed. >> >> [1] http://mutabit.com/repos.fossil/doctorado-offray/ >> >> Cheers, >> >> Offray >> >> >

Oct. 29, 2017

Re: [Pharo-users] [GT] moldable tools for non-developers

by Stephane Ducasse

Hi offray What I would like to know is what are the kind of mathematical support you need for your data analyses and that is not support by polymath. I'm "working" (well sweet dream) on future book on collective intelligence, basic AI stuff and I think that roassal is cool but you need to have also filtering and empowering the data. So what did you miss? I want powerful data journalists (they are important for our world). Stef On Fri, Oct 27, 2017 at 8:38 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Hi Sebastian, > > > On 27/10/17 13:15, Sebastian Heidbrink via Pharo-users wrote: >> that is kind of what I am looking for. Would you mind if I contacted >> you directly? >> I am in the process of formulizing a master thesis and would love to >> bring Pharo into the mix. >> > > No problem. Contact me. This weekend is a little bit busy with some > deadlines I need to reach, but next week is fine. > >> Is you phd thesis public? > It is at [1], with a public repository of the research artifacts since > 2011 (before open research was in fashion :-P), but it is in Spanish. > Sorry. I didn't have the time to clarify my mind about this research and > also improve my English. But I would be glad to discuss it in English > with you or anyone interested. You're very welcomed. > > [1] http://mutabit.com/repos.fossil/doctorado-offray/ > > Cheers, > > Offray > >

Oct. 29, 2017

Re: [Pharo-users] Binary Decision Diagram Package in Smalltalk

by Stephane Ducasse

Thanks I think that the sets will be known since the scanner definition should not changed once defined. Now andrew told me that he could use an existing solution but not build one because he should make progress on his compiler. But Steffen if you know how to build such package it would be a nice addition and we will use it. Stef On Sat, Oct 28, 2017 at 5:37 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Does that mean the sets/bdd would be constructed mainly at comile time? > Anyway, Andrew, feel free to contact me, I might help you with this. > > Best, Steffen > > > Am .10.2017, 16:05 Uhr, schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > >> I think that andrew would like to improve smacc when parsing inputs >> containing utf-8 characters. >> >> >> On Sat, Oct 28, 2017 at 1:46 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >>> >>> I see. What is the task in detail? Are some of the set fixed or known in >>> advance? What's the argument against a bitset-based solution? >>> >>> Cheers, Steffen >>> >>> >>> >>> Am 27. Oktober 2017 19:10:35 MESZ schrieb Stephane Ducasse >>> <stepharo.self(a)gmail.com>: > > <---Schnitt---> >>> >>> >> > > >

Oct. 29, 2017

Re: [Pharo-users] Actual Code to Improve the Pharo environment

by Stephane Ducasse

Ok tell us when you release something. having a little example would be really nice. On Sat, Oct 28, 2017 at 5:25 PM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > Iâm not working on that specifically, although what I am working on could > definitely use that and vice versa, which would increase the capabilities > of each. > > > > One thing Iâm working on is using Vert.x for service registration and > discovery, mapped to Apache River (JINI) to propagate that over non-local > network segments that require fully authenticated security (as a result, it > also provides things such as Kerberos to Pharo apps). The mapping between > the two is very straightforward, almost direct, but Iâve added the Synapse > micro service bus to control data flows and secure access to remote > services. > > > > It enables things like automatic configuration/integration of Pharo based > mobile apps with newer cars that support that kind of autoconfiguration, > since they all use JINI to do so. Thus a Pharo mobile or IoT app can > automatically be configured to work with any of the carâs subsystems that > are relevant to it. > > > > JINI is far more used than people realize, partly because it âjust worksâ > and as a result doesnât get the public âsqueaky wheelâ effect. The fact > that the authors of Vert.x reimplemented half of the features of JINI, in a > less comprehensive and less reliable way, rather than just using it > (especially considering itâs open source) shows the degree to which that > effect is operative. > > > > Thereâs probably a couple dozen other general use cases where the > integration will allow Pharo apps to âjust workâ in a JINI or Vert.x > environment, as well as thousands of industry/company specific ones. Iâd > have to mode-switch to think of them off the top of my head though ð. > > > > Andrew > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *henry <henry(a)callistohouse.club> > *Sent: *Saturday, October 28, 2017 10:02 AM > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject: *Re: [Pharo-users] Actual Code to Improve the Pharo environment > > > > Hi Andrew, > > > > Are you working to bring a Capabilities model to Pharo? This is precisely > what I am working to bring with Hubbub, running on top of my ParrotTalk. I > derived these from erights.org's ELib and have been working on them for > many years. Now that ParrotTalk has stabilized (layer 5) I am shifting to > implementing marshalling of layer 6 objects using STON all to run on top of > ParrotTalk. Once I get marshalling with scope substitutions, I will debug > Hubbub to offer distributed Capabilities. > > > > What work are you undertaking? > > > > Regards, > > - HH > > > > > > -------- Original Message -------- > > Subject: Re: [Pharo-users] Actual Code to Improve the Pharo environment > > Local Time: October 28, 2017 9:12 AM > > UTC Time: October 28, 2017 1:12 PM > > From: aglynn42(a)gmail.com > > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > > > Writing that kind of code is another of the reasons I decided I donât want > to work in anything else ð. Maybe more important than some of the > others, both to myself and to other users. > > > > Iâve gained so much personally, mostly for nothing, even just considering > the relatively few projects I *have* been able to work on in Pharo and > previously in Squeak, VW and VA. Unfortunately in most I havenât been able > to make the code public, since they were for entities like the government, > DoD, etc. > > > > Not that VA attracts me quite so much to give back all that strongly, when > a license is $8500+. Were it possible to give back to VA C++ or VA Java, > it might be different, but neither were OSS although they werenât > expensive. More relevantly, both are now abandonware (hence my comment > about IBM, which is applicable to OS/2 as well, although that has quietly > had a 5.0 version released in June of this year). > > > > I would, though, love a chance to give back to Pharo primarily, although I > may port anything relevant to Squeak, and if I have sufficient time port it > to VW, which although not OSS is at least affordable to most developers. > > > > Iâm nearly there on a couple of projects â one Iâm testing and making > final tweaks, another is about 2/3dâs of the way. > > > > The first project you (and others on the list) may be more immediately > interested in testing, since it requires little to no additional work to > use it, and even if not perfect, since itâs intended to directly help work > you *are* doing in Pharo, it may worthwhile. Iâm hoping to have it ready > for public consumption by the middle of November. > > > > On a different but related topic, the article I wrote got a fair amount of > interest considering I donât write nearly as well as Kenneth, for example. > Including direct interest from some well known industry people, which canât > hurt. In an indirect way it may even be helpful, but not in the real, > direct way decent code is. > > > > Capabilities that wonât be available in anything else in an really usable > way (because to be efficient they depend on capabilities not found in > anything else), and in any case nowhere near as useful in anything else, > will hopefully be more use than any article can be, never mind one I wrote, > not just to me but also to other Pharo users and to Pharo itself. > > > > Cheers > > Andrew Glynn > > > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *Stephane Ducasse <stepharo.self(a)gmail.com> > > *Sent: *Saturday, October 28, 2017 5:09 AM > > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > *Subject: *Re: [Pharo-users] Smalltalk Argument > > > > Hi andrew > > > > please take a project that would help to bring more companies and that you > want to push and push it with us :). > > > > > > Stef > > > > > > On Sat, Oct 28, 2017 at 11:05 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> wrote: > > Hi andrew > > > > you should contact esteban because he is writing an objective-C bridge. > > > > Stef > > > > On Sat, Oct 28, 2017 at 2:30 AM, Andrew Glynn <aglynn42(a)gmail.com> wrote: > > One thing Iâm working on is a bridge between Pharo and F-Script. F-Script > is, basically, a Smalltalk dialect, as is obvious from the screenshot. > However for MacOS and iOS, it allows you to bypass the static Objective-C > API interface and debug / modify or even write applications directly in the > system. To do that you âinjectâ F-Script into the OS. The ability to so > has a specific implication, though. MacOS and iOS are themselves written > in and as a dialect of Smalltalk. (were it simply an overlay on > Objective-C, it wouldnât be able to do things that are impossible in > Objective-C, and it wouldnât need to be âinjectedâ in order to run). Every > implementation of Objective-C , bar GNUâs useless imitation, compiles to > Smalltalk. No surprise that Appleâs does, as well. > > > > In any event, it will allow Pharo code to be mapped to MacOS and iOS > objects, injected into the system dynamically, and modified / debugged > dynamically using the Pharo tools. The result, at least as far as iOS is > concerned, may make Pharo actually the most powerful way to program it, > well beyond XCode alone, along with doing the same for MacOS. Android is > another issue, although the Raspbian port of Pharo should be relatively > easy to port to it. For me, unless someone had a use case, I donât have one > myself for Android. Iâve tried nearly every version, because Iâd love to > support an OSS ecosystem, unfortunately using it compared to the iPhone is > still like driving a Fiero based kit car compared to an actual Ferrari. > > > > As far as JNI, while I see your point, JNI is such a PITA that few Java > developers know it. My usual workaround is to use Stamp and Synapse, which > has the further advantage of allowing Java to âthrottleâ data that the JVM > canât deal with at full speed. > > > > As far as dealing with other JVM languages, PetitParser or SmaCC can > generate bytecode rather than Java or other JVM code, and that allows libs > to be written that utilize Synapse to talk to Pharo. It isnât necessarily > an ideal solution, but a possible one without having to support umpteen > environments. Another potential way of accomplishing that is to use > NetRexx, a declarative JVM language, which is both easy and terse, and like > SQL, generates the actual bytecode rather than precompiling to it. For > instance, imagine the code needed for a simple âhello worldâ in Java, then > compare: > > > > Say âhello worldâ > > > > Since it generates virtually the same bytecode, it may be an easy way to > do it. > > > > With the last statement, that expresses really well the exact reason I no > longer want to work in most other environments ð. > > > > Tc > > Andrew > > > > > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for > Windows 10 > > > > *From: *phil(a)highoctane.be > > *Sent: *Thursday, October 26, 2017 2:19 AM > > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > > *Subject: *Re: [Pharo-users] Smalltalk Argument > > > > 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 > > > > > > > > > > > > > > > > > > On Thu, Oct 26, 2017 at 12:46 AM, Andrew Glynn <aglynn42(a)gmail.com> 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. Being inefficient, as long as it doesnât âreallyâ matter, > is an advantage to large enterprises because they have resources smaller > competitors donât. > > > > Why donât their competitors do it? Because they canât see past an hourly > rate, whatâs fashionable, or just new, or because their customers canât. > Put more generally, average stupidity that isnât corrected by the market. > Fashion affects smaller companies more than larger ones, because they canât > afford a few customers walking away because they wanted an app in Electron, > even if they canât give any relevant reason for wanting it, and even the > samples on the Electron site donât work. > > > > Enterprises can, and do use Smalltalk when it matters. When it doesnât, > itâs to their advantage to promote things that are inefficient, buggy and > unreliable. > > > > Cost is relevant, but not in the simple way people look at things. A > crucial but rarely mentioned perspective on its relevance is that while > Java based software runs TV set top boxes, Smalltalk based software runs > things like medical equipment, automated defense systems, tanks, etc. Cost > becomes largely irrelevant when âshit has to workâ. > > > > Productivity is primarily relevant to less talented developers, in an > inversely sense, since unproductive environments and attitudes have a > leveling tendency in general, and more specifically make accomplishing what > the less talented are capable of in any environment sufficiently laborious > for them to have a role. Capability in Smalltalk, as implied by the person > hiring for the Java role I mentioned, is a fairly decent means of judging > whether someone is a so-so developer or a good one. > > > > The productivity argument is realistically only relevant in the context of > an already higher hourly cost. Given that it is relevant at that point, > companies that know Smalltalk is more productive would use it outside > things that have to be 100%, *if* their own productivity were relevant to > the same degree that competitorsâ productivity is inversely relevant. > > > > All these ways of looking at it are contingent perspectives though. Yes, > if the number of libraries is relevant to you, Smalltalk is less > attractive, but thatâs only a contingent phenomenon based on the relative > popularity of Java and JavaScript, as a result it canât be used as > explanatory *for* that popularity. All the ways of looking at it that > are fully determinate are determinate via contingencies of that kind, which > for the most part *are* precisely the other perspectives, including > productivity, cost, availability of developers, etc. None of them is *in > itself* anything but a result of the others. > > > > If availability of developers is contingent on popularity (and further, > popularity contingent on industry attitudes), to use an example already > mentioned in Joachimâs post, then his simultaneous posit of library > availability is if anything more contingent on the same popularity, so > positing it as a cause and not a result, or merely a correlate, of > popularity is incoherent. We can go one step further, and demonstrate that > even when large enterprises make something that works reliably available, > they fail to promote and support it, which destroys the market for reliable > tooling by simultaneously owning it while not promoting it, something IBM > is particularly good at. But IBM canât (and if they canât, neither can any > other company) operate that way without the tacit agreement of the > industry. > > > > To understand it in a more general way, software development has to be > looked at in the context where it occurs, and how itâs determined to a > large degree by that context, with a specific difference. That difference > is itself implicit in the context, i.e. capitalism, but only *purely *effective > in software development. Itâs a result of virtualization as an implicit > goal of capitalism, and the disruptions implicit in the virtual but so far > only realized completely in software. In terms of that understanding, the > analysis of virtualization and disruption as inherent to capitalism is > better accomplished in Kapital than in any more recent work. > > > > Or you can simply decide, as Iâve done recently, that working in ways and > with tools that prevent doing good work in a reasonable timeframe isnât > worthwhile *to you,* no matter how popular those ways and tools might be, > or what the posited reasons are, since at the end popularity is only > insofar as it *already* is. What those tools and methods are depends to > a degree on your priorities, but if developers are *engineers* those > priorities canât be completely arbitrary. Engineers are defined by their > ability to make things work. > > > > Software as virtual is inherently disruptive, and the software industry > disrupts itself too often and too easily to build on anything. A further > disruption caused by developers, *as* engineers, refusing to work with > crap that *doesnât*, i.e. insisting on being engineers, while in itself > merely an aggravation of the disruptive tendencies, might have an inverse > result. > > > > Using a stable core of technologies as the basis for a more volatile set > of products, in the way nearly every other industry does, is the best means > we know of to build things both flexibly and reasonably efficiently. The > computer hardware industry is the extreme example of this, while the > software industry is the extreme contradiction. > > > > *From: *Pharo-users <pharo-users-bounces(a)lists.pharo.org> on behalf of > David Mason <dmason(a)ryerson.ca> > *Reply-To: *Any question about pharo is welcome < > pharo-users(a)lists.pharo.org> > *Date: *Tuesday, October 24, 2017 at 11:52 AM > *To: *Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject: *Re: [Pharo-users] Smalltalk Argument > > > > PharoJS is working to give you that mobile app/browser app experience. As > with others, we're not there yet, but getting there. See > http://pharojs.org > > > > The 67% loved means that 67% of people using Smalltalk (or perhaps have > ever used it) want to continue - so it's presumably a high percentage of a > smallish number of people. > > > > On 20 October 2017 at 03:23, jtuchel(a)objektfabrik.de < > jtuchel(a)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&feel, 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 > > > -- > ----------------------------------------------------------------------- > Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > Fliederweg 1 http://www.objektfabrik.de > D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 > > > > > > > > > > > > > > > > >

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by henry

I have heard this summarized by the term: "build it and they will come". I think the data visualization aspect is where Pharo entering BigData space could really payoff. That comes down to data manipulation. Can Pharo read Avro? - HH On Sun, Oct 29, 2017 at 14:00, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > Thanks a lot Paulo for starting this thread and all the participants for the clever and enlightening answers. I just want to add my two cents. On 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as pessimistic it may sound, Smalltalk has > very little to offer in the library front. The language is still > stellar and live environment is a great concept but from there on > there is a decline. Sure if your are low demand kind of person on the > library front and dont mind implementing stuff by yourself you wont > mind the lack of libraries but most coders , me included , dont have > this luxury. Especially making a living with a language is a > completely different story from learning it as a hobby, > > I think and that's a personal opinion, that Smalltalk goes the wrong > direction. It tries to be a do it all language, but we already have an > army of do it all languages. I think it would excel as the backbone in > big complex projects. Like the Moose project is doing with code > analysis and visualization. I think this is an excellent direction to > go with Smalltalk. Reflection is the big strength of Smalltalk the > ability to communicate with its code in a direct matter. So I think > that a Smalltalk implementation that can analyze and visualize code > written in other languages would have been a pretty serious reason for > people to learn Smalltalk. > > I am very happy to see Pharo go towards that direction and yes I would > definitely recommend it without hesitation for code analysis and > project management tool. Its no coincidence that we have seen a > serious growth in our community. When I joined back in 2011 we all > were posting at pharo-dev, pharo-users was a dead zone and then the > community grow larger and larger we soon may need a third mailing list. > > Code complexity is an issues for all large projects and tools that > help manage this without having to convert to another language are > very popular. About finding niche where you can learn Pharo and make a living from it, I think that I may be behind a sweet spot in the field of reproducible research and data storytelling and visualization, for different fields like activism, journalism, science and engineering. I'm "working in my PhD", so I don't get paid for using Pharo & friends (well if fact I'm in a loan to finish my PhD), but using Pharo have allowed my to get more dynamic results that with previous technologies (mostly Python and Web ones). By being able to prototype quickly I have improved my research experience and results, which is a way to improve research (self) funding. Also, activists, journalist, researchers and other novices interested in data storytelling and visualization, care little about popularity of the language or being able to make apps (mobile or web). What they care is about being able to tell the story and Pharo, agile visualization and moldable tools, have a lot to offer in this front. They're easy to learn and to adapt to fit the needs of the problems behind those stories, as we have done with Grafoscopio[1]. So, is nice to be part of a "trend", (data science, reproducible research, data storytelling and data visualization) but not being part of one that doesn't give you the freedom to use tools that matter to you, because of the ideas they embody and the added value they create for you and your community. [1] http://mutabit.com/grafoscopio/index.en.html Also, being in Latin America, means that we can bootstrap ourselves into alternative futures by using alternative (digital) infrastructures and tools, without to much worry about the deep investments in money and/or expertise on bloated/popular technologies (we don't have such investments here!). We can learn from the experience of the "Global North", without following that path, but by taking a critical approach to it (for example regarding overcomplex, non-dynamic, bloated technologies). On the community front, I think is important to do something to break the circular logic of popularity: Smalltalk is unpopular, so we don't get developers, so we don't have libraries, and this makes such tech unpopular. We're a nascent community of data storytellers and activists learning how to use Pharo to tell our voices and how to modify the tools to tell them in more potent/fluid ways. We have done this mostly by ourselves, without any support from industry or government and mostly none from academy. Despite of the fragility of our hackerspace[2], this has been done in a consistent way since almost two years[3] (I started to learn Pharo, in a sparse way, 3 years ago). So, there are ways to break the circular logic and bootstrap communities around the advantages of the Pharo/Smalltalk environment in places where it can be aligned to the trends but also take a critical approach to them by providing added value. [2] http://hackbo.co/ [3] http://mutabit.com/dataweek/ So finding a niche and bootstrapping tools and communities in it, seems a way to deploy the Smalltalk Argument by example into the world, which is a pretty powerful way to argument against skeptics. Cheers, Offray

Oct. 29, 2017

Re: [Pharo-users] Smalltalk Argument

by Offray Vladimir Luna CÃ¡rdenas

Thanks a lot Paulo for starting this thread and all the participants for the clever and enlightening answers. I just want to add my two cents. On 26/10/17 07:53, Dimitris Chloupis wrote: > > My personal opinion is that as pessimistic it may sound, Smalltalk has > very little to offer in the library front. The language is still > stellar and live environment is a great concept but from there on > there is a decline. Sure if your are low demand kind of person on the > library front and dont mind implementing stuff by yourself you wont > mind the lack of libraries but most coders , me included , dont have > this luxury. Especially making a living with a language is a > completely different story from learning it as a hobby,Â > > I think and that's a personal opinion, that Smalltalk goes the wrong > direction. It tries to be a do it all language, but we already have an > army of do it all languages. I think it would excel as the backbone in > big complex projects. Like the Moose project is doing with code > analysis and visualization. I think this is an excellent direction to > go with Smalltalk. Reflection is the big strength of Smalltalk the > ability to communicate with its code in a direct matter. So I think > that a Smalltalk implementation that can analyze and visualize code > written in other languages would have been a pretty serious reason for > people to learn Smalltalk.Â > > I am very happy to see Pharo go towards that direction and yes I would > definitely recommend it without hesitationÂ for code analysis and > project management tool. Its no coincidence that we have seen a > serious growth in our community. When I joined back in 2011 we all > were posting at pharo-dev, pharo-users was a dead zone and then the > community grow larger and larger we soon may need a third mailing list.Â > > Code complexity is an issues for all large projects and tools that > help manage this without having to convert to another language are > very popular. About findingÂ niche where you can learn Pharo and make a living from it, I think that I may be behind a sweet spot in the field of reproducible research and data storytelling and visualization, for different fields like activism, journalism, science and engineering. I'm "working in my PhD", so I don't get paid for using Pharo & friends (well if fact I'm in a loan to finish my PhD), but using Pharo have allowed my to get more dynamic results that with previous technologies (mostly Python and Web ones). By being able to prototype quickly I have improved my research experience and results, which is a way to improve research (self) funding. Also, activists, journalist, researchers and other novices interested in data storytelling and visualization, care little about popularity of the language or being able to make apps (mobile or web). What they care is about being able to tell the story and Pharo, agile visualization and moldable tools, have a lot to offer in this front. They're easy to learn and to adapt to fit the needs of the problems behind those stories, as we have done with Grafoscopio[1]. So, is nice to be part of a "trend", (data science, reproducible research, data storytelling and data visualization) but not being part of one that doesn't give you the freedom to use tools that matter to you, because of the ideas they embody and the added value they create for you and your community. [1] http://mutabit.com/grafoscopio/index.en.html Also, being in Latin America, means that we can bootstrap ourselves into alternative futures by using alternative (digital) infrastructures and tools, without to much worry about the deep investments in money and/or expertise on bloated/popular technologies (we don't have such investments here!). We can learn from the experience of the "Global North", without following that path, but by taking a critical approach to it (for example regarding overcomplex, non-dynamic, bloated technologies). On the community front, I think is important to do something to break the circular logic of popularity: Smalltalk is unpopular, so we don't get developers, so we don't have libraries, and this makes such tech unpopular. We're a nascent community of data storytellers and activists learning how to use Pharo to tell our voices and how to modify the tools to tell them in more potent/fluid ways. We have done this mostly by ourselves, without any support from industry or government and mostly none from academy. Despite of the fragility of our hackerspace[2], this has been done in a consistent way since almost two years[3] (I started to learn Pharo, in a sparse way, 3 years ago). So, there are ways to break the circular logic and bootstrap communities around the advantages of the Pharo/Smalltalk environment in places where it can be aligned to the trends but also take a critical approach to them by providing added value. [2] http://hackbo.co/ [3] http://mutabit.com/dataweek/ So finding a niche and bootstrapping tools and communities in it, seems a way to deploy the Smalltalk Argument by example into the world, which is a pretty powerful way to argument against skeptics. Cheers, Offray

Oct. 29, 2017

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

by 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 > Â Â Â <apicall: Literal constant expected -> 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 <sheidev(a)yahoo.de> >> Date: >> 10/25/2017 03:47 PM >> >> To: >> pharo-users(a)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. >

Oct. 29, 2017

Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations

by Andrew Glynn

Thanks, great description ð. From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of henry Sent: Sunday, October 29, 2017 1:56 AM To: Ben Coman <btc(a)openinworld.com> Cc: Pharo-users list <pharo-users(a)lists.pharo.org>; Pharo Development List <pharo-dev(a)lists.pharo.org>; Squeak-dev <squeak-dev(a)lists.squeakfoundation.org> Subject: Re: [Pharo-users] [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations Yes well it is an extension to what you found as I combined with eventual references such that it computes in a single thread. - HH On Sat, Oct 28, 2017 at 23:59, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com> > wrote: On Thu, Oct 26, 2017 at 12:00 AM, henry <henry(a)callistohouse.club <mailto:henry@callistohouse.club> > wrote: I disabled vatId authorization in version 3, located in SessionOperations>> processIWant | SessionOperations>>processIAm: . I was asked to disseminate my news to Pharo Users, hello there. I was asked to describe ParrotTalk well, provide use cases and adopters of its use. Alright, I will give an attempt. ParrotTalk is an encrypted connection framework. Currently allowing anonymous 2048-bit key negotiation to establish user-provided encryption cipher and user-provided encoding and decoding, both through a provided SessionAgentMap to a starting SessionAgent server. Please look in the test case ThunkHelloWorldTest for building these maps and running a connection iwth data passing after encryption is established. There is a 4-way negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 signature validation and DH 2048 primes to establish the key used within the selected Cipher. The Cipher and Encoder are selected by name through the negotiation protocol. Currently three Ciphers are selectable, AESede, DESede, and DES. There are two encoders tested, asn1der, and Bytes. This protocol is described here, in this document. https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr… For as to use cases, this encrypted connection has no third party, man-in-the-middle situation by not using Certificates. As such, this is a tight implementation of NSA-proof encryption without explicit authorization beyond knowledge of a host:port. The use cases involve any communication desired to be encrypted with such high encryption. The support will last my lifetime, so we have a settled solution, here in the third version, provided here. It requires version 111 of Cryptography, as a prerequisite. Both run on Squeak and Pharo. http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz The current use is with my hubbub system, a promise-based distributed object implementation. I am working to bring ParrotTalk to Java and allow hubbub to operate interdependently between Squeak, Pharo, Java and any other languages which can support ParrotTalk and STON. My latest efforts with hubbub are to bring STON as the Layer 6 encoding. Hubbub depends on eLinda. Took me a while to track down what eLinda was. I presume its an implementation of Linda "a model of coordination and communication among several parallel processes operating upon objects stored in and retrieved from shared, virtual, associative memory" https://en.wikipedia.org/wiki/Linda_(coordination_language) http://www.cs.yale.edu/publications/techreports/tr984.pdf cheers -ben

Oct. 29, 2017

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

by 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 <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 Â Â Â <apicall: Literal constant expected -> 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 <sheidev(a)yahoo.de> > Date: > 10/25/2017 03:47 PM > > To: > pharo-users(a)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.

Oct. 29, 2017

Re: [Pharo-users] What is code 137 / how to gracefully shut down via SIGTERM?

by Herby VojÄÃk

werner kassens wrote: > Hi Herby, > eventually you might want to look at > https://github.com/moby/moby/issues/1063 > but then i dont know anything about these things. Hopefully they have this solved already... but I learned 137 means "killed". generally; did not know. :-) > werner Herby

Oct. 29, 2017