Hi, I'm use the Ruby programming language as my primary language work wise. However, I find myself always coming back to the Smalltalk language. Thus, I have the following questions:
a) How does one use hook methods within the VW Smalltalk environment? I'm not 100% sure if this a standard feature across all Smalltalk environments. In Ruby, it's simply a way to hook into underlying interpreter. Lastly, a reference would suffice.
b) In Ruby, one can define method implementations within a module and use them within a module or class. I believe in Smalltalk it goes by the term traits. Thus, is there a recommended implementation used across Smalltalk environments or simply VW Smalltalk.
c) What type(s) of concurrency models exist for VW Smalltalk? STM? Actor Model?
Thanks in advance,
-Conrad _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On Wed, Jun 8, 2011 at 9:00 PM, Conrad Taylor <[hidden email]> wrote:
Hi, I'm use the Ruby programming language as my primary language work wise. However, I find myself always coming back to the Smalltalk language. Thus, I have the following questions: To clarify: In Ruby, it's commonly referred to as meta-programming. Thus, I'm guessing that a similar term is used within the Smalltalk community.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Conrad Taylor
I haven't used Ruby, so it's hard to know if I am understanding right.
But let's see :)... I googled hook methods and I came up with lists such as http://blog.firsthand.ca/2010/09/ruby-hook-methods.html and http://stackoverflow.com/questions/5127819/is-this-a-comprehensive-list-of-ruby-hook-methods Now, assuming (perhaps too much) what those methods mean, it looks like these allow a program to be aware of modifications made to it while the program is running. For example, in http://blog.sidu.in/2007/12/rubys-methodadded.html it looks like method_added is called by the runtime whenever a method is added to a class. So it sounds like what you're looking for is a mechanism to be notified when classes change. To be more specific, it sounds like you're interested to be notified when a class gets a new method, or when someone subclasses it, or when the instance variables change. If you are looking for a Smalltalk equivalent to Ruby's hook methods, I'd say probably these facilities depend on the particular tool set installed in the Smalltalk image. I'm sure others in this list are more familiar with VisualWorks' tool set and metaprogramming notifications than I am (I work with other things most of the time), so I'd rather defer to them. But in the mean time I hope to have helped with the question :). On 6/8/2011 9:00 PM, Conrad Taylor wrote: > Hi, I'm use the Ruby programming language as my primary language work > wise. However, I find myself always coming back to the Smalltalk > language. Thus, I have the following questions: > > a) How does one use hook methods within the VW Smalltalk environment? > I'm not 100% sure if this a standard feature across all Smalltalk > environments. In Ruby, it's simply a way to hook into underlying > interpreter. Lastly, a reference would suffice. > > b) In Ruby, one can define method implementations within a module and > use them within a module or class. I believe in Smalltalk it goes by > the term traits. Thus, is there a recommended implementation used > across Smalltalk environments or simply VW Smalltalk. > > c) What type(s) of concurrency models exist for VW Smalltalk? STM? > Actor Model? > > Thanks in advance, > > -Conrad > > > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Conrad Taylor
> b) In Ruby, one can define method implementations within a module and
> use them within a module or class. I believe in Smalltalk it goes by > the term traits. Thus, is there a recommended implementation used > across Smalltalk environments or simply VW Smalltalk. A trait is a mechanism by which, assuming a bunch of methods is defined in terms of some kernel methods, you can mount the bunch on top of the kernel without having to implement the bunch every single time. I'd say Traits are optional. In Smalltalk you can define a method implementation (always within a class, because that's the only place you can put methods in) within a module (or package, or category, or application depending on the particular source code management system... in VW you'd likely say "package"). When the package is loaded, you can then call the implemented methods from other packages. Andres. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Conrad Taylor
> c) What type(s) of concurrency models exist for VW Smalltalk? STM?
> Actor Model? In Smalltalk you have green threads. Most Smalltalk implementations currently support one active green thread at a time. For concurrency, usually the approach is to run multiple Smalltalk images and allow them to communicate with each other. The GemStone object database goes really well with this approach. But of course I am sure I am missing something, so I also defer somewhat :). Andres. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
... to clarify...
If you need simultaneous concurrency, i.e.: what's usually referred as a multithreaded app, then currently most Smalltalk implementations resort to running multiple virtual machines which communicate somehow (e.g.: through GemStone). If you need concurrency in terms of having multiple processes running in the image (although usually only one at a time will run), then it's usually a matter of writing something like ["do some stuff"] fork Andres. On 6/9/2011 12:57 AM, Andres Valloud wrote: >> c) What type(s) of concurrency models exist for VW Smalltalk? STM? >> Actor Model? > > In Smalltalk you have green threads. Most Smalltalk implementations > currently support one active green thread at a time. For concurrency, > usually the approach is to run multiple Smalltalk images and allow them > to communicate with each other. The GemStone object database goes > really well with this approach. But of course I am sure I am missing > something, so I also defer somewhat :). > > Andres. > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Conrad Taylor
a) I tried to understand method hooks by reading the following post:
http://cheind.blogspot.com/2008/12/method-hooks-in-ruby.html In VisualWorks you could use Store (the version control system) “Method overrides”. Read PDF “Source Code Management Guide”, section “Overriding Definitions”. Basically, in a package B that depends on package A, you implement a method that replaces the implementation in A. So, there is no execution of the implementation in A (like Ruby?). Like hooks, there can only be one (active) override for a method. Method overrides are specific to VisualWorks. b) You are on the right track... Traits are not used by default in VisualWorks. You should also consider structuring your code so you do not need this support. c) Others gave good answers to this one. I want to add that VisualWorks includes a framework named “Polycephaly”, which basically lets you manage worker/child/drone images from a VisualWorks image. Each worker image runs in its own OS process. Read more about its use on my blog. Runar Jordahl blog.epigent.com _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Conrad Taylor
Method hooks sounds a lot like the Method Wrappers package included
with VisualWorks. Like lots of things in Smalltalk, it's not built
in to the language, the language is just rich enough to allow you to
implement it as a library, which is what was done in this case.
I'm not sure what you mean about using a method implementation within a module. In VisualWorks there are packages, and you can certainly implement methods within one. Implementing methods on a class which exists elsewhere is commonly referred to as a class extension. But Traits are a whole other mechanism. VisualWorks has a concurrency model with the class Process, which are threads in more recent terminology, but are "green threads" in that they are lightweight and not mapped to operating system threads. Calls to external systems can be mapped to operating system threads for concurrency, and there are various implementations people have built on top of things. I remember things people built with the Actor model a long time ago in Smalltalk, but I'm not sure of anything currently maintained. Gemstone is essentially an STM system, but I'm not aware of anything for VisualWorks. Polycephaly is a package that allows you to run multiple communicating images fairly easily to take advantage of multiple cores or CPUs, but is a distributed memory model. I guess I'm not sure what you're looking for.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
I just had an idea, possibly a very bad one. If we want multiple Smalltalk images to communicate, how about just using files? Obviously very slow, but perhaps if the files were on a RAM disk? Still, very low level, but perhaps if the files were actually a database? Nasty O-R mapping stuff, but perhaps if we used an object repository? Again, slow because of lots of serializing and deserializing, but perhaps can be ameliorated with repositories that cache already-loaded objects in the image, and use swap-out proxies so once loaded, objects work at full speed with no proxies in between. Interestingly, that’s exactly the situation we have with MetaEdit+’s multi-user version. The clients communicate with the server (itself a little Smalltalk program) partly through files and partly through sockets, with most traffic being through sockets along which the server pumps the data it reads from files. The repository (ArtBASE) has full ACID transactions, with the choice of any combination of pessimistic and optimistic concurrency control. I’m no STM expert, but that sounds surprisingly similar. Although we never intended to build something like that, our need to support multiple people working simultaneously on a set of inter-related data is, at its most basic, essentially the same as multiple copies of a program working simultaneously on a set of data: just consolidate the server and clients from their separate machines onto a single multi-core machine. Since I just got a shiny new quad-core computer, I’ll have to give it a try! Steve --
Alan Knight wrote: [hidden email]
… c) What type(s) of concurrency models exist for VW Smalltalk? STM? Actor Model? Thanks in advance, -Conrad _______________________________________________ _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Runar Jordahl
Dear Conrad,
like Runar >a) I tried to understand method hooks by reading the following post: >http://cheind.blogspot.com/2008/12/method-hooks-in-ruby.html > > and I note from its text "Method-Hooks provide a way to intercept method calls on objects ... The keyword following is a method name that takes any number of method symbols and a block. Its semantic is to execute the code block immediately after the given methods are called. ..." To me, this looks like a MethodWrapper. One subclass of MethodWrapper is BlockMethodWrapper. It has settable before and after blocks which will be executed before and after the calling of any methods on which it is installed. The code comments in the blogpost's example # Backup original method, make backup private # Replace method # Invoke backup # Invoke Hook remind me of a BlockMethodWrapper with 'after' block set (except that installation and execution seem to be the same operation in the Ruby) which executes behaviour around its target but does not replace it (of course, a block wrapper can replace by returning from the before block, and ConditionalMethodWrapper, for example, runs its block _instead_ _of_ the target when its condition is not met). IIUC, the blogpost's 'Following' implementation, from a Smalltalk viewpoint, seems to be more like renaming and reimplementing the method (calling the rename from the reimplementor) than how a method wrapper works, but with the same intent as a MethodWrapper. One could of course do this rename/reimplement programmatically in Smalltalk, but one would more often use a method wrapper. This rename/reimplement is somethines done explicitly in Smalltalk by refactorings, e.g. by deprecation frameworks, to make the deprecation more visible in code browsers. Also Michel Tilman's Zork-Analysis, and the equivalent VA tool, parse the method and reimplement it to collect intra-method type information. I think AspectS and suchlike interweaving tools use Method Wrappers but they may (in some implementations) reimplement. All Smalltalk dialects I use have mature method wrapper implementations. They are not loaded in the base as they are seen as power-user rather than naive-user tools. They are much used in code analysis tools - call tracing, lightweight dead code detection, polymorphic refactoring, etc. - and in testing. In my experience, they are rarely used in actual production code, though certainly used to test and analyse production code. The other responders in this thread seem to have different takes on what it was you were asking / what "method hook" means, and of course they may be right and I wrong. HTH. Yours faithfully Niall Ross | | >In VisualWorks you could use Store (the version control system) >“Method overrides”. Read PDF “Source Code Management Guide”, section >“Overriding Definitions”. Basically, in a package B that depends on >package A, you implement a method that replaces the implementation in >A. So, there is no execution of the implementation in A (like Ruby?). >Like hooks, there can only be one (active) override for a method. > >Method overrides are specific to VisualWorks. > >b) You are on the right track... Traits are not used by default in >VisualWorks. You should also consider structuring your code so you do >not need this support. > >c) Others gave good answers to this one. I want to add that >VisualWorks includes a framework named “Polycephaly”, which basically >lets you manage worker/child/drone images from a VisualWorks image. >Each worker image runs in its own OS process. Read more about its use >on my blog. > >Runar Jordahl >blog.epigent.com > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steven Kelly
Dear Steve
>I just had an idea, possibly a very bad one. > Quite a good one actually, as some very demanding apps use it. >If we want multiple >Smalltalk images to communicate, how about just using files? Obviously >very slow, but perhaps if the files were on a RAM disk? Still, very low >level, but perhaps if the files were actually a database? Nasty O-R >mapping stuff, but perhaps if we used an object repository? > GemStone is used in just this way by certain multi-image VW applications (and I think by VA ones too though I'd have to check my notes). > Again, slow > because of lots of serializing and deserializing, but perhaps can be > ameliorated with repositories that cache already-loaded objects in the > image, and use swap-out proxies so once loaded, objects work at full > speed with no proxies in between. One can also do clever things in the hardware (via shared page caches, etc.). Anyone attending ESUG will be able to meet experts in at least one of these apps in Edinburgh in late August. Yours faithfully Niall-always-plugging-the-conference-Ross :-) >Interestingly, that's exactly the situation we have with MetaEdit+'s >multi-user version. The clients communicate with the server (itself a >little Smalltalk program) partly through files and partly through >sockets, with most traffic being through sockets along which the server >pumps the data it reads from files. The repository (ArtBASE) has full >ACID transactions, with the choice of any combination of pessimistic and >optimistic concurrency control. > > > >I'm no STM expert, but that sounds surprisingly similar. Although we >never intended to build something like that, our need to support >multiple people working simultaneously on a set of inter-related data >is, at its most basic, essentially the same as multiple copies of a >program working simultaneously on a set of data: just consolidate the >server and clients from their separate machines onto a single multi-core >machine. > > > >Since I just got a shiny new quad-core computer, I'll have to give it a >try! > > > >Steve > > > >------------------------------------------------------------------------ > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Conrad Taylor
Conrad c) As other have mentioned the Smalltalk concurrency model uses green threads. It is quite powerful and satisfies most requirements, an exception being the need to distribute actual work. Issues a and b are best answered by someone who is familiar with both Ruby and Smalltalk. Generally speaking it is can be misleading to attempt to use one’s prior language experience when learning a language that uses a different paradigm. In many situations, Smalltalk is different enough that you would be better off simply learning the Smalltalk way by going though the tutorials and documentation. Terry From: [hidden email] [mailto:[hidden email]] On Behalf Of Conrad Taylor Hi, I'm use the Ruby programming language as my primary language work wise. However, I find myself always coming back to the Smalltalk language. Thus, I have the following questions: a) How does one use hook methods within the VW Smalltalk environment? I'm not 100% sure if this a standard feature across all Smalltalk environments. In Ruby, it's simply a way to hook into underlying interpreter. Lastly, a reference would suffice. b) In Ruby, one can define method implementations within a module and use them within a module or class. I believe in Smalltalk it goes by the term traits. Thus, is there a recommended implementation used across Smalltalk environments or simply VW Smalltalk. c) What type(s) of concurrency models exist for VW Smalltalk? STM? Actor Model? Thanks in advance, -Conrad _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steven Kelly
On Thu, Jun 9, 2011 at 6:22 AM, Steven Kelly <[hidden email]> wrote:
I
implemented exactly this kind of setup a while back. 1 master image
that wrote out files -- actually BOSS files. Then each child image
polled a common directory looking for work to do. And while it worked, it is not suited for any kind of high speed communications. I had it running a large set of jobs that took 5-10min each for each job. Since the communication was across a network share, I just started images on as many machines as I could get my hands on. Running on 18 cores got the job done overnite instead of taking weeks. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On 09.06.2011, at 19:00, Jon Paynter wrote: > I implemented exactly this kind of setup a while back. 1 master > image that wrote out files -- actually BOSS files. Then each child > image polled a common directory looking for work to do. > > And while it worked, it is not suited for any kind of high speed > communications. I had it running a large set of jobs that took > 5-10min each for each job. Since the communication was across a > network share, I just started images on as many machines as I could > get my hands on. Running on 18 cores got the job done overnite > instead of taking weeks. Polycephaly is certainly also great for such kind of long running tasks. However, speaking of communication via files, BOSS serialization, or other similar techniques, this has actually nothing to do anymore with the term "multi-threading". IMO these are merely workarounds for special niche applications. When I started my application design many years ago, I thought the Smalltalk green threads would be sufficient. I learned the hard way that they are not. My regular development machine is an 8-Core and I got tired of seeing only one core at 100% most of the time. Now I find myself porting back large portions of my products to C++ in order to be able to leverage the hardware and keep up with the requirements. Andre _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Conrad Taylor
On Wed, Jun 8, 2011 at 9:00 PM, Conrad Taylor <[hidden email]> wrote:
Hi, I'm use the Ruby programming language as my primary language work wise. However, I find myself always coming back to the Smalltalk language. Thus, I have the following questions: Hi, I would like to thank everyone for replying to post and I really appreciate it. I'll take the time to refresh myself with the VWNC environment as well as the Smalltalk programming language which I found on an old Time Machine backup. This should be good enough until I receive the CD/DVD from Cincom.
Thanks again, -Conrad
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |