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

[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  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  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
>> 
> 
> 

Re: [Pharo-users] Pharo 6.1

[Ben Coman]

On Tue, Oct 31, 2017 at 3:27 AM, Викентий Потапов  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

Re: [Pharo-users] Pharo 6.1

[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/wg6l98bj64q6hgvs23wwqyprgn/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, Викентий Потапов  
> 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
> 

[Pharo-users] Pharo 6.1

[Викентий Потапов]

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

[Pharo-users] Microsoft COM

[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

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

[Paulo R. Dellani]

Hi Pablo,

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

Cheers,

Paulo

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

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

[teso...@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.

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


-- 
Pablo Tesone.
teso...@gmail.com

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

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

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

[Paulo R. Dellani]

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

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

Cheers, Paulo

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

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

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

[Paulo R. Dellani]

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

pharo --version:

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

uname -a

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


On 10/30/2017 01:02 PM, Paulo R. Dellani wrote:
> Dear uFFI experts,
>
> I am dealing with the port of the ZeroMQ
>  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

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

[Paulo R. Dellani]

Dear uFFI experts,

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

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

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

Cheers,

Paulo