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

Re: [Pharo-users] UK Smalltalk User Group Meeting - Monday, October 30th - PharoLambda: Smalltalk running serverless on AWS

by Tim Mackinnon

I promised to give a little summary of the meetup. After some initial âsmalltalkâ (in the talking sense - where we covered chrome books, cloud development, squeakjs and how you might develop in smalltalk on a Chromebook in a web worldâ¦. I did say smalltalk right)â¦. I did a quick intro to the components of writing a traditional Alexa Skill and Lambda functions on AWS using Node JSâ¦ this wasnât Smalltalk related but it set the context of what the environment is like and was quite interesting to the group to give some some background. We had some interesting side conversations on the social aspects of having a device like an Echo Dot in your living room (is it like the revolution weâve had with phones? Does it feel natural etc). Some interesting debate on this. Then we covered how the recentâish advancement with an OpenSmalltalk 64bit vm have given the ability to easily run Smalltalk no Lambda where you donât have a lot of control on what is installed on your target instance (essentially you upload a zip file of your environment) We then walked through the GitLab CI/build system I used to automatically create a zip file to upload (the minimal image work done here was the power behind this - and GitLab ci is quite a nice build system that is fast/efficient and simple to use). Then the real eye-opener was looking at the small amount of code needed to create a service (not so amazing actually) - but the kicker being the implications of how you can easily debug a failed service. This got the conversation flowing. The 2 interesting points that came out: - restarting a failed service (and being able to keep restarting it in a debugger) is neat - but services often have other elements like a database or other service that also need rewinding. Given the tiny amount of code that I showed that serialises the context to S3 (again, sponsored by this community - thanks) its not unimaginable to snapshot a database and be able to restore it when you dematerialise your execution context (and also do it again if you decide to restart again). These are things developers in other communities donât even dream of doing it seems. (As a side point - how hard would it be for our debugger to truly let you rewind memory when you step back in the stack?) - AWS feels like a new operating system. And just like we handle restoring windows and other resources on an OS like windows - should we be viewing AWS as a similar thing we should run on (albeit in a slightly different way). But can our tooling/environment make for a more pleasant and cohesive view on top of a cloud OS? It feels like it could somehow. - Another side point - I recall early demos of IBM distributed smalltalk where you could literally highlight nodes of execution that were slow because they were far apart and just drag them near to each other so that message calls didnât have the same network latency. This feels like the new cloud world might benefit from some of these old ideasâ¦ not sure if there are any video of this in action to inspire people. Anyway - not sure if any of this is useful to anyone reading, but it may be a reminder to me of things to follow up on. Tim > On 27 Oct 2017, at 17:58, Tim Mackinnon <tim(a)testit.works> wrote: > > Thanks Sean - hoping to do a bit of deeper dive into the Screencast I posted a while back - but Iâm also hoping we can get some discussion around the kinds of things we can do with serverless that match the strengths of Smalltalk. > > Iâve got a few ideas - but wondering what others think - and weâll share the results here. > > Tim > > NOTE for anyone that is coming and is reading this: Weâve had to change the venue to the pub around the corner - The Crown Tavern. > >> On 27 Oct 2017, at 16:31, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Tim Mackinnon wrote >>> Tim Mackinnon will showâ¦ >> >> So jealous! That sounds like an awesome presentation :) >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> > >

Oct. 31, 2017

Re: [Pharo-users] Pharo 6.1

by Ben Coman

On Tue, Oct 31, 2017 at 3:27 AM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² <vikenti.potapov(a)gmail.com > wrote: > > I've just downloaded Pharo 6.1 from pharo.org, unzipped it and started. > And i've got an error: > "UTF8InvalidText: Invalid utf8 input detected" > > Whether i save image or not, every time i start it i get the same error. > > System: win 7 professional x64 on 6-core Athlon Phenom. > Locale: russian (cyrillic). > > Can i fix it by myself or i should forget about 6.1 until global bugfix? > > Vikenti Potapov > > I downloaded yesterday and again just now and no problem unzipping and running. URL: http://files.pharo.org/platform/Pharo6.1-win.zip System: Win 10 Professional x64 What folder do you unzip into? Does it contain any non-ASCII characters? Double check copy-pasting into somewhere like http://asciivalue.com/ Could you create folder C:\Pharo ensuring all ASCII characters, and try unzipping into there? cheers -ben

Oct. 31, 2017

Re: [Pharo-users] Pharo 6.1

by Todd Blanchard

I was just preparing a similar post. Just downloaded latest Pharo 6.1-64 for Mac I was greeted with a walkback when it failed to create directory /private/var/folders/ks/wg6l98bj64q6hgvs23wwqypr0000gn/T/AppTranslocation/DAA5EA3A-374D-4ADE-9E04-BBB7433BB6C8/d/Pharo6.1-64.app/Contents/Resources/pharo-local Definitely not the right directory to resolve pharo-local to. -Todd Blanchard > On Oct 30, 2017, at 12:27 PM, ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð² <vikenti.potapov(a)gmail.com> wrote: > > > I've just downloaded Pharo 6.1 from pharo.org, unzipped it and started. And i've got an error: > "UTF8InvalidText: Invalid utf8 input detected" > > Whether i save image or not, every time i start it i get the same error. > > System: win 7 professional x64 on 6-core Athlon Phenom. > Locale: russian (cyrillic). > > Can i fix it by myself or i should forget about 6.1 until global bugfix? > > Vikenti Potapov >

Oct. 30, 2017

Pharo 6.1

by ÐÐ¸ÐºÐµÐ½ÑÐ¸Ð¹ ÐÐ¾ÑÐ°Ð¿Ð¾Ð²

I've just downloaded Pharo 6.1 from pharo.org, unzipped it and started. And i've got an error: "UTF8InvalidText: Invalid utf8 input detected" Whether i save image or not, every time i start it i get the same error. System: win 7 professional x64 on 6-core Athlon Phenom. Locale: russian (cyrillic). Can i fix it by myself or i should forget about 6.1 until global bugfix? Vikenti Potapov

Oct. 30, 2017

Microsoft COM

by Ben Coman

Hi Pablo, At work I managed to remote control Internet Explorer with Excel VBA like this... [1] http://www.automateexcel.com/vba/automate-internet-explorer and went looking for how similar might be achieved from Pharo. IIUC I discovered this would be done via Microsoft's Component Object Model, and then I bumped into your repo... [2] https://github.com/tesonep/pharo-com Could you advise the status and your plans for this? Since I see its only a few months old I've probably stumbled onto it prematurely, but I see no documentation or tests to discover how to use it. So I'll curious whether it makes something like [1] possible? And could you show how that would be done? cheers -ben P.S. For context, at work I automated IE since the intranet document management system (OpenText) does authentication via a javascript function in the browser, which doesn't compute with Microsoft's MSXML.DOMDocument component. So I use IE to do the authentication and grab the raw XML from IE to then stuff it into MSXML.DOMDocument from which I pull the data I need. But I'd love to do it with Pharo instead (if I can get IT to white list it) cheers -ben

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

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