Can we get to see vasslthreads.h?

Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.

vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.

Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:

Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.

vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.

Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:

Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:

Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.

vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.

Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:

Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

Hi Lou

System osProcessId

-- Seth

On Sunday, September 9, 2018 at 2:30:28 PM UTC-4, Louis LaBrunda wrote:

Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:

Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.

vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.

Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:

Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

On Mon, Sep 10, 2018 at 6:32 PM Louis LaBrunda <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="tIl8W23bBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">L...@...> wrote:

Hi Andres,

Thanks for the information and the explanation.  It is always helpful to see the big picture.  I expect Seth's recommendation to use "System osProcessId" means the VM has obtained the PID in the proper manner and we can feel safe using it to get the PID.

Hi Lou,

Yes, I personally think #osProcessId is safer because it ends up calling a VM primitive. This is NOT a FFI call. 

 

Cheers,

Lou

On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:

Hello,

The function getpid() is governed by POSIX, and virtually all POSIX functions can also be a macro:

<a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html

This means that, even if there is a function called 'getpid', you still do not know (and you are not even supposed to know) if there is a macro called 'getpid' that does something like this:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

Therefore, if it's one of those functions that POSIX says is allowed to be a macro (i.e., any of them), that function should never be called via FFI at all because the behavior isn't guaranteed to be what you would get from a C compiler.  If you call such functions anyway, you're asking for strange "VM bugs" nobody can diagnose and that later on get papered over as "compiler bugs", or "kernel bugs", or "heisenbugs", etc.  The reality is that using an FFI like that is asking for undefined behavior, as in "anything and everything becomes possible".

I'm not saying there are no compiler or kernel bugs --- but if those do exist and are affecting your program, the number one requirement to file a bug against those programs is following the relevant documentation to the letter.  Spec lawyering is not always fun, but I care that my program works and that carries me over the occasional annoyance.

The picture changes on a per platform basis, and one has to be aware of these things.  On Windows, for instance, it's a different story --- in there, usually when MSDN says 'there is a function called foo() that...', it really means there is an actual function called foo() visible to the users, and so you can call that via an FFI.  Be aware, however, that once you do that then all the rules of C apply to your program.  For the sake of illustration, Windows API calls change behavior depending on which thread is calling them.  This is just one example out of an exceedingly large list.

In summary, using an FFI to call C programs turns you into a C programmer regardless of whether you happen to be notating such usage in Smalltalk.

Andres.

On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda <[hidden email]> wrote:

Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:

Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.

vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.

Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:

Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="tIl8W23bBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="tIl8W23bBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@....
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--

Mariano Martinez Peck
Software Engineer, Instantiations Inc.
<a href="javascript:" target="_blank" gdf-obfuscated-mailto="tIl8W23bBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">mp...@...

Hello,

The function getpid() is governed by POSIX, and virtually all POSIX functions can also be a macro:

<a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html

This means that, even if there is a function called 'getpid', you still do not know (and you are not even supposed to know) if there is a macro called 'getpid' that does something like this:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

Therefore, if it's one of those functions that POSIX says is allowed to be a macro (i.e., any of them), that function should never be called via FFI at all because the behavior isn't guaranteed to be what you would get from a C compiler.  If you call such functions anyway, you're asking for strange "VM bugs" nobody can diagnose and that later on get papered over as "compiler bugs", or "kernel bugs", or "heisenbugs", etc.  The reality is that using an FFI like that is asking for undefined behavior, as in "anything and everything becomes possible".

I'm not saying there are no compiler or kernel bugs --- but if those do exist and are affecting your program, the number one requirement to file a bug against those programs is following the relevant documentation to the letter.  Spec lawyering is not always fun, but I care that my program works and that carries me over the occasional annoyance.

The picture changes on a per platform basis, and one has to be aware of these things.  On Windows, for instance, it's a different story --- in there, usually when MSDN says 'there is a function called foo() that...', it really means there is an actual function called foo() visible to the users, and so you can call that via an FFI.  Be aware, however, that once you do that then all the rules of C apply to your program.  For the sake of illustration, Windows API calls change behavior depending on which thread is calling them.  This is just one example out of an exceedingly large list.

In summary, using an FFI to call C programs turns you into a C programmer regardless of whether you happen to be notating such usage in Smalltalk.

Andres.

On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="mC0gMS6RBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">L...@...> wrote:

Hi Seth,

Given what you say in this and your next post which library would you suggest?  Should I stick with vasslthreads?

Lou

On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman wrote:

Hi Lou,

The function <a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">getpid is not really in vasslthreads.so.  getpid is an exported function from libc.so that is "reachable" via vasslthreads.so because of the linker.

vasslthreads library is really an internal thread-locking library required by consumers of OpenSSL versions < 1.1.0 to achieve thread-safety. 

So as long as you can reach libc...you'll get access to getpid.

Example...these all answer the same thing because they all link to libc.

(PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so' #() #uint32)) call

(PlatformFunction fromArray: #('C' 'getpid' nil 'vasslthreads.so' #() #uint32)) call.

-- Seth

On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis LaBrunda wrote:

Hi,

The other day I wanted to get the PID of the running VM.  I played around and found that the getpid function was in vasslthreads.so.  I'm wondering what else may be in vasslthreads that is useful.  So, can we please see vasslthreads.h so we can see what it can do?

I think there is a way of asking Linux for a list of the names of the functions in vasslthreads but it would be much easier to have the source.

Lou

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="mC0gMS6RBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="mC0gMS6RBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@....
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

In a nutshell, each project deploys modularity boundaries in different
ways, using whatever mechanisms provided by the language.

For example, since these functions can be macros, whoever is maintaining
them can change the implementation of the method^H^H^H^H^H^H function
without affecting the senders^H^H^H^H^H^H^H callers.

That's just one of the mechanisms in play.  The expectation is that you
will use POSIX via a C compiler, otherwise the behavior is undefined.

That the POSIX functions are governed with those rules is someone else's
choice.  Apparently it's a reasonable choice because people keep using
said functionality.  So let's use the POSIX functions as intended.

Different project, different rules to follow.

Andres.

On 9/11/18 08:36, Louis LaBrunda wrote:

> Hi Andres,
>
> I have been thinking about your post and while I believe what you say is
> true I wonder why it is true, meaning why would things be built that
> way?  This is not a criticism of anything you have said and I expect
> your advice is sound.  I'm just wondering why things are the way they
> are.  My knowledge in this area is very old, much of it predates the
> invention of C.  So, I may use terms that don't quite match the modern
> definitions.
>
> Lets say we have a program, a library and a function, defined in and
> supported by the library.  Back in the old days of computing, not so far
> back that there weren't operating systems but very far back, a library
> could either be compiled as part of a program or separately.  If
> separately, the OS needed to be involved with linking and binding and
> loading in order for a program to get to and use a function.  If
> compiled together, there was less of that.  There were also macros.  A
> macro was a group of instructions, its use allowed a programmer to write
> one line of code instead of many but there wasn't any magic that turned
> a function into a macro.  Back when memory was costly (I worked on an
> early IBM mainframe that had 1 MB of ram and a second MB cost half a
> million dollars) programmers had to decide to use functions because they
> took up less memory or macros because the were faster.
>
> I can image one of todays compilers being smart enough to look at a
> function definition and decide to automatically (maybe governed by
> options) make it a macro and in-line the code in the program that calls
> the function.  Even if this is the case, I don't see why the library
> can't be compiled separately and linked with the function in it in a way
> that the function is externalized and can be called by programs via the
> OS.  If this is the case and even if a function has been compiled in a
> program as a macro, the program should be able to call a function of the
> same name via the OS and get the function to run in the library.
>
> I don't know how this works with C and on modern computers but I would
> expect that there is an opcode (hardware based) that tells the OS that
> it wants something special done (the OS would define what and how that
> works) this would be how programs get external functions run.  I don't
> see the program needing to know anything more about the library and
> function than names and what needs to be passed back and forth.  The
> fact the the same function has been turned into a macro in the program
> shouldn't matter.
>
> Maybe I am way off in terms of how I imagine things can work, if so,
> that's the way it goes.  But if not and things are exactly as you say,
> than that would be a shame.
>
> Lou
>
>
>
> On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
>
>     Hello,
>
>     The function getpid() is governed by POSIX, and virtually all POSIX
>     functions can also be a macro:
>
>     <a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html <<a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html>
>
>     This means that, even if there is a function called 'getpid', you
>     still do not know (and you are not even supposed to know) if there
>     is a macro called 'getpid' that does something like this:
>
>     #define getpid(x, y, z) do { \
>              __never_call_this_getpid(x, y, z); \
>              getpid(x, y, z); \
>     } while (0)
>
>     Therefore, if it's one of those functions that POSIX says is allowed
>     to be a macro (i.e., any of them), that function should never be
>     called via FFI at all because the behavior isn't guaranteed to be
>     what you would get from a C compiler.  If you call such functions
>     anyway, you're asking for strange "VM bugs" nobody can diagnose and
>     that later on get papered over as "compiler bugs", or "kernel bugs",
>     or "heisenbugs", etc.  The reality is that using an FFI like that is
>     asking for undefined behavior, as in "anything and everything
>     becomes possible".
>
>     I'm not saying there are no compiler or kernel bugs --- but if those
>     do exist and are affecting your program, the number one requirement
>     to file a bug against those programs is following the relevant
>     documentation to the letter.  Spec lawyering is not always fun, but
>     I care that my program works and that carries me over the occasional
>     annoyance.
>
>     The picture changes on a per platform basis, and one has to be aware
>     of these things.  On Windows, for instance, it's a different story
>     --- in there, usually when MSDN says 'there is a function called
>     foo() that...', it really means there is an actual function called
>     foo() visible to the users, and so you can call that via an FFI.  Be
>     aware, however, that once you do that then all the rules of C apply
>     to your program.  For the sake of illustration, Windows API calls
>     change behavior depending on which thread is calling them.  This is
>     just one example out of an exceedingly large list.
>
>     In summary, using an FFI to call C programs turns you into a C
>     programmer regardless of whether you happen to be notating such
>     usage in Smalltalk.
>
>     Andres.
>
>
>     On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda
>     <[hidden email] <javascript:>> wrote:
>
>         Hi Seth,
>
>         Given what you say in this and your next post which library
>         would you suggest?  Should I stick with vasslthreads?
>
>         Lou
>
>         On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman
>         wrote:
>
>             Hi Lou,
>
>             The function getpid
>             <<a href="http://man7.org/linux/man-pages/man2/getpid.2.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">http://man7.org/linux/man-pages/man2/getpid.2.html>is not
>             really in vasslthreads.so.  getpid is an exported function
>             from libc.so that is "reachable" via vasslthreads.so because
>             of the linker.
>             vasslthreads library is really an internal thread-locking
>             library required by consumers of OpenSSL versions < 1.1.0 to
>             achieve thread-safety.
>
>             So as long as you can reach libc...you'll get access to getpid.
>             Example...these all answer the same thing because they all
>             link to libc.
>
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil
>             'vasslthreads.so' #() #uint32)) call.
>
>             -- Seth
>
>             On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis
>             LaBrunda wrote:
>
>                 Hi,
>
>                 The other day I wanted to get the PID of the running
>                 VM.  I played around and found that the getpid function
>                 was in vasslthreads.so.  I'm wondering what else may be
>                 in vasslthreads that is useful.  So, can we please
>                 see vasslthreads.h so we can see what it can do?
>
>                 I think there is a way of asking Linux for a list of the
>                 names of the functions in vasslthreads but it would be
>                 much easier to have the source.
>
>                 Lou
>
>         --
>         You received this message because you are subscribed to the
>         Google Groups "VA Smalltalk" group.
>         To unsubscribe from this group and stop receiving emails from
>         it, send an email to va-smalltalk...@googlegroups.com <javascript:>.
>         To post to this group, send email to [hidden email]
>         <javascript:>.
>         Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk
>         <<a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk>.
>         For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout
>         <<a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="dJBTaszqBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com
> <mailto:<a href="javascript:" target="_blank" gdf-obfuscated-mailto="dJBTaszqBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk+unsubscribe@...>.
> To post to this group, send email to <a href="javascript:" target="_blank" gdf-obfuscated-mailto="dJBTaszqBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@...
> <mailto:<a href="javascript:" target="_blank" gdf-obfuscated-mailto="dJBTaszqBwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@googlegroups.com>.
> Visit this group at <a href="https://groups.google.com/group/va-smalltalk" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
> For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

You see it as a booby trap because the way that code is designed does not support the non standard usage that you want.

The same code can also be seen as a feature of modularity and backwards compatibility targeting the intended majority audience who use the code as per the manual.

That you cannot imagine why does not prove it's wrong.

It's no use arguing to be more correct than the authors.  POSIX just does not work that way.

IIRC, in some versions of AIX, there is no memset() function visible to an FFI.

On Wed, Sep 12, 2018, 14:59 Louis LaBrunda <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="zGRaRPAsCAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">L...@...> wrote:

Hi,

On Tuesday, September 11, 2018 at 4:56:46 PM UTC-4, Andres Valloud wrote:

I'd be more interested in "why wouldn't they".

I'm always interested in "why" things are the way they are.  In an earlier post you gave some example code:

#define getpid(x, y, z) do { \
        __never_call_this_getpid(x, y, z); \
        getpid(x, y, z); \
} while (0)

have you ever actually seen code like this in a library?  I have a hard time imagining why anyone would write code like it.  If one doesn't want a function to work, just leave it out of the library.  An error will be returned and that's it.  Why write a booby trap?

Lou

 

On Tue, Sep 11, 2018, 19:45 Louis LaBrunda <[hidden email]> wrote:

Hi Andres,

I understand that things are the way they are and I guess that there are rules to follow.  But I don't understand why someone couldn't compile a library as an external library like an so or DLL with the functions defined with external linkage and then be called by other programs.

Lou

On Tuesday, September 11, 2018 at 12:56:55 PM UTC-4, Andres Valloud wrote:

In a nutshell, each project deploys modularity boundaries in different
ways, using whatever mechanisms provided by the language.

For example, since these functions can be macros, whoever is maintaining
them can change the implementation of the method^H^H^H^H^H^H function
without affecting the senders^H^H^H^H^H^H^H callers.

That's just one of the mechanisms in play.  The expectation is that you
will use POSIX via a C compiler, otherwise the behavior is undefined.

That the POSIX functions are governed with those rules is someone else's
choice.  Apparently it's a reasonable choice because people keep using
said functionality.  So let's use the POSIX functions as intended.

Different project, different rules to follow.

Andres.

On 9/11/18 08:36, Louis LaBrunda wrote:

> Hi Andres,
>
> I have been thinking about your post and while I believe what you say is
> true I wonder why it is true, meaning why would things be built that
> way?  This is not a criticism of anything you have said and I expect
> your advice is sound.  I'm just wondering why things are the way they
> are.  My knowledge in this area is very old, much of it predates the
> invention of C.  So, I may use terms that don't quite match the modern
> definitions.
>
> Lets say we have a program, a library and a function, defined in and
> supported by the library.  Back in the old days of computing, not so far
> back that there weren't operating systems but very far back, a library
> could either be compiled as part of a program or separately.  If
> separately, the OS needed to be involved with linking and binding and
> loading in order for a program to get to and use a function.  If
> compiled together, there was less of that.  There were also macros.  A
> macro was a group of instructions, its use allowed a programmer to write
> one line of code instead of many but there wasn't any magic that turned
> a function into a macro.  Back when memory was costly (I worked on an
> early IBM mainframe that had 1 MB of ram and a second MB cost half a
> million dollars) programmers had to decide to use functions because they
> took up less memory or macros because the were faster.
>
> I can image one of todays compilers being smart enough to look at a
> function definition and decide to automatically (maybe governed by
> options) make it a macro and in-line the code in the program that calls
> the function.  Even if this is the case, I don't see why the library
> can't be compiled separately and linked with the function in it in a way
> that the function is externalized and can be called by programs via the
> OS.  If this is the case and even if a function has been compiled in a
> program as a macro, the program should be able to call a function of the
> same name via the OS and get the function to run in the library.
>
> I don't know how this works with C and on modern computers but I would
> expect that there is an opcode (hardware based) that tells the OS that
> it wants something special done (the OS would define what and how that
> works) this would be how programs get external functions run.  I don't
> see the program needing to know anything more about the library and
> function than names and what needs to be passed back and forth.  The
> fact the the same function has been turned into a macro in the program
> shouldn't matter.
>
> Maybe I am way off in terms of how I imagine things can work, if so,
> that's the way it goes.  But if not and things are exactly as you say,
> than that would be a shame.
>
> Lou
>
>
>
> On Monday, September 10, 2018 at 9:34:39 AM UTC-4, Andres Valloud wrote:
>
>     Hello,
>
>     The function getpid() is governed by POSIX, and virtually all POSIX
>     functions can also be a macro:
>
>     <a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html <<a href="http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fpubs.opengroup.org%2Fonlinepubs%2F009695399%2Fbasedefs%2Funistd.h.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHARgN9jTnBneddgOM4gqyG9jVzxw&#39;;return true;">http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html>
>
>     This means that, even if there is a function called 'getpid', you
>     still do not know (and you are not even supposed to know) if there
>     is a macro called 'getpid' that does something like this:
>
>     #define getpid(x, y, z) do { \
>              __never_call_this_getpid(x, y, z); \
>              getpid(x, y, z); \
>     } while (0)
>
>     Therefore, if it's one of those functions that POSIX says is allowed
>     to be a macro (i.e., any of them), that function should never be
>     called via FFI at all because the behavior isn't guaranteed to be
>     what you would get from a C compiler.  If you call such functions
>     anyway, you're asking for strange "VM bugs" nobody can diagnose and
>     that later on get papered over as "compiler bugs", or "kernel bugs",
>     or "heisenbugs", etc.  The reality is that using an FFI like that is
>     asking for undefined behavior, as in "anything and everything
>     becomes possible".
>
>     I'm not saying there are no compiler or kernel bugs --- but if those
>     do exist and are affecting your program, the number one requirement
>     to file a bug against those programs is following the relevant
>     documentation to the letter.  Spec lawyering is not always fun, but
>     I care that my program works and that carries me over the occasional
>     annoyance.
>
>     The picture changes on a per platform basis, and one has to be aware
>     of these things.  On Windows, for instance, it's a different story
>     --- in there, usually when MSDN says 'there is a function called
>     foo() that...', it really means there is an actual function called
>     foo() visible to the users, and so you can call that via an FFI.  Be
>     aware, however, that once you do that then all the rules of C apply
>     to your program.  For the sake of illustration, Windows API calls
>     change behavior depending on which thread is calling them.  This is
>     just one example out of an exceedingly large list.
>
>     In summary, using an FFI to call C programs turns you into a C
>     programmer regardless of whether you happen to be notating such
>     usage in Smalltalk.
>
>     Andres.
>
>
>     On Sun, Sep 9, 2018 at 11:30 AM, Louis LaBrunda
>     <[hidden email] <javascript:>> wrote:
>
>         Hi Seth,
>
>         Given what you say in this and your next post which library
>         would you suggest?  Should I stick with vasslthreads?
>
>         Lou
>
>         On Sunday, September 9, 2018 at 12:38:02 PM UTC-4, Seth Berman
>         wrote:
>
>             Hi Lou,
>
>             The function getpid
>             <<a href="http://man7.org/linux/man-pages/man2/getpid.2.html" rel="nofollow" target="_blank" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fman7.org%2Flinux%2Fman-pages%2Fman2%2Fgetpid.2.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEk8G1y3lZj4WopcvwBDhDuEo9A-A&#39;;return true;">http://man7.org/linux/man-pages/man2/getpid.2.html>is not
>             really in vasslthreads.so.  getpid is an exported function
>             from libc.so that is "reachable" via vasslthreads.so because
>             of the linker.
>             vasslthreads library is really an internal thread-locking
>             library required by consumers of OpenSSL versions < 1.1.0 to
>             achieve thread-safety.
>
>             So as long as you can reach libc...you'll get access to getpid.
>             Example...these all answer the same thing because they all
>             link to libc.
>
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'libc.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil 'esvm40.so'
>             #() #uint32)) call
>             (PlatformFunction fromArray: #('C' 'getpid' nil
>             'vasslthreads.so' #() #uint32)) call.
>
>             -- Seth
>
>             On Sunday, September 9, 2018 at 9:30:51 AM UTC-4, Louis
>             LaBrunda wrote:
>
>                 Hi,
>
>                 The other day I wanted to get the PID of the running
>                 VM.  I played around and found that the getpid function
>                 was in vasslthreads.so.  I'm wondering what else may be
>                 in vasslthreads that is useful.  So, can we please
>                 see vasslthreads.h so we can see what it can do?
>
>                 I think there is a way of asking Linux for a list of the
>                 names of the functions in vasslthreads but it would be
>                 much easier to have the source.
>
>                 Lou
>
>         --
>         You received this message because you are subscribed to the
>         Google Groups "VA Smalltalk" group.
>         To unsubscribe from this group and stop receiving emails from
>         it, send an email to va-smalltalk...@googlegroups.com <javascript:>.
>         To post to this group, send email to [hidden email]
>         <javascript:>.
>         Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk
>         <<a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk>.
>         For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout
>         <<a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout>.
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "VA Smalltalk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to va-smalltalk...@googlegroups.com
> <mailto:va-smalltalk+[hidden email]>.
> To post to this group, send email to [hidden email]
> <mailto:va-sma...@googlegroups.com>.
> Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
> For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To post to this group, send email to [hidden email].
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="zGRaRPAsCAAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-smalltalk...@googlegroups.com.
To post to this group, send email to <a href="javascript:" rel="nofollow" target="_blank" gdf-obfuscated-mailto="zGRaRPAsCAAJ" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">va-sma...@....
Visit this group at <a href="https://groups.google.com/group/va-smalltalk" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/va-smalltalk&#39;;return true;">https://groups.google.com/group/va-smalltalk.
For more options, visit <a href="https://groups.google.com/d/optout" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.