Vm-dev June 2010

vm-dev@lists.squeakfoundation.org

42 participants
52 discussions

ffi-test-main.c fails on FreeBSD
by Gary Dunn 12 Aug '16

12 Aug '16

In conjunction with getting Open Cobalt running on FreeBSD I have been looking into the problems with SqueakFFIPrims on FreeBSD and have reached a point that is beyond my understanding. I am not sure if the fix should come from the VM side or the FreeBSD port maintainer. I needed to get source code back into the ports tree so I did a make in /usr/ports/lang/squeak. I already had the 3.9 tarball, so that just repopulated the source and did the initial build. In the "files" folder I found patch files typical for a FreeBSD port. These patch source files from a generic tarball to work with FreeBSD. The one of interest was patch-platforms__unix__plugins__SqueakFFIPrims__ffi-config which contains ----x-----x----- --- platforms/unix/plugins/SqueakFFIPrims/ffi-config.org Wed Apr 26 20:27:53 2006 +++ platforms/unix/plugins/SqueakFFIPrims/ffi-config Wed Apr 26 20:29:00 2006 @@ -39,6 +39,7 @@ case ${abi} in linux) abi=sysv;; + freebsd*) abi=sysv;; darwin*) abi=darwin;; *) abi=libffi; lib="-lffi";; esac -----x-----x----- I then had the folder work/Squeak-3.9-7/platforms/unix/plugins/SqueakFFIPrims In it is a file 00README which explains how to test FFI. It says to run ffi-test-config but I have no such file. It says to type "make" to build a test suite but the build failed. It says to try with make CPU=any ABI=libffi LIB=-lffi which also failed. I traced the problem to the gcc search paths for includes and libraries -- turns out FreeBSD only searches /usr/include and /usr/lib when the required files are in /usr/local/include and /usr/local/lib. After some fiddling I finally had a "main" to test. It failed: ffi-test-main.c failed at line 361. Here is a bit from that file, ending with line 361: ffiInitialize(); for (ul= 0; ul < 15; ++ul) ffiPushSingleFloat(fa[ul]); GO(FFITypeSingleFloat, many); f= ffiReturnFloatValue(); ffiCleanup(); CHECK(f - ff < FLT_EPSILON); I worked out the CHECK macro but could not find what FLT_EPSILON is. At that point I decided to stop and come to you for help. Where do I go from here? -- Gary Dunn, Honolulu osp(a)aloha.com http://openslate.net/ http://e9erust.blogspot.com/ Sent from Slate001

5 8

Profiling and delay accuracy
by Andreas Raab 06 Aug '11

06 Aug '11

Hi Folks - For a long time now I had this feeling that MessageTally reports pretty bogus results in many situations without being able to precisely track down why this would be the case. Today I was looking at primitiveResponse() and, much to my surprise, noticed that the checkForInterrupts() that used to be there for years is gone (see Squeak3.6 for example which still has it). The sole reason for this check was to get both high delay accuracy and good profiling behavior. Consider this example: fc := FormCanvas on: Display. MessageTally spyOn:[ 1 to: 100 do:[:i| fc fillColor: Color white. fc printString. ]. ]. Using 3.6 this will be measured correctly as: **Tree** 87.5% {243ms} FormCanvas>>fillColor: |87.5% {243ms} GrafPort>>fillRect:offset: | 87.5% {243ms} GrafPort>>copyBits 12.5% {35ms} FormCanvas(Object)>>printString 12.5% {35ms} FormCanvas(Object)>>printStringLimitedTo: whereas the 3.10 reports it as **Tree** 99.6% {670ms} FormCanvas(Object)>>printString 94.9% {639ms} primitives 4.6% {31ms} FormCanvas(Object)>>printStringLimitedTo: I think you can see the problem and just imagine what this does to any cumulative results. I also wonder what that change does to platforms that don't have high-resolution asynchronous timers. This used to be the one place where we would catch timer changes at high resolution and unless the platform forces high resolution timer interrupts asynchronously (by resetting the interrupt counter) we must be loosing a lot in terms of delay accuracy. (it just so happens that the Windows VM *does* do asynchronous timer interrupts so I never noticed this but I'm very curious about the difference on Linux which typically still has pretty bad timer granularity). Any opinions? My feeling is that the timer check should go back in for all of the above reasons. At the very least a quickCheckForInterrupt() is required but I actually think putting the full check back in is worth it. Cheers, - Andreas

3 3

4.0.3.2196 for Unix
by Ian Piumarta 08 May '11

08 May '11

Folks, Source and binaries for Linux/i386, Darwin/i386 & Darwin/PPC now available. (Solaris, NetBSD and FreeBSD still at 3.11.3 until I get my kvm working again.) http://squeakvm.org/unix Enjoy! Ian Major changes since 3.11.3.2135: Generated sources rebuilt from VMMaker-dtl.169. Re-enabled MIDI support via ALSA on Linux. Broken locales should no longer cause line ends to go missing during copy and paste. Add support for "platform source version" primitive. Remove debugging beep on first clipboard copy under X11. Allow fully-qualified pathnames when loading modules. Bundle FreetypePlugin with source and binary releases. Various fixes for 64-bit cleanliness (many thanks to Dave Lewis). Add microsecond clock support. Fix launching from a menu under KDE. Fix --CFLAGS option in configure script. Serial plugin invalidates cached port names on close. Better handling of symlinks when looking for absolute path to VM binary.

5 12

Joys of Squeak-dev image, VM Compiling on MacIntel and Spoon remote OtherBrowsing
by Ken G. Brown 16 Nov '10

16 Nov '10

MacPro OS X 10.4.9 Xcode 2.4.1 Squeak-dev-114-2, VMMaker 2.8b6.1, Squeak 3.8.15beta6U.app, and version 1657 of svn MacOS VM sources, and Spoon v2a12. Downloaded http://www.squeakvm.org/cgi-bin/viewcvs.cgi/ trunk version 1657 for MacOS Ran squeak-dev-beta-114-2.image on Squeak 3.8.15beta6U.app Loaded VMMaker 3.8b6.1 from dev image Universes. Generated vm sources by following instructions in <http://www.squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Mac%20OS/vm/Doc…> Fought with Xcode wanting to use MacOSX10.3.9.sdk for ppc which was giving an error which was known and documented in the Readme. Finally figured out what Xcode wanted so built universal app just using 10.4.9 sdk. Couple issues: Exupery references remain in sqnamedPrims.h and sqPlatformSpecific.h from svn version 1657, I just commented them out. Notes said: Info-NPSqueak__Upgraded_.plist was to be found in the Developer directory. I could not find it so scammed a info.plist out of John's Squeak 3.8.15beta6U.app vm. Not sure what impact this has. And much, much diddling about figuring out various things... Finally got a build. It's a lot smaller (3.9MB) than John McIntosh's Squeak 3.8.15beta6U.app (8.1MB), and it looks like it is a PowerPC one but at least it runs. I'll look into the Xcode build process some more. Then: Replaced interp.c with Craig's interp.c for Spoon, rebuilt and got a VM with Spoon client stuff. Downloaded Spoon release 2a12. Moved a copy of Flow plugin from within Craig's naiad.app package into a plugins subdirectory where the new spoon client compatible MacIntel universal VM was run from. Followed Craig's Spoon instructions for loading niaid.st and niaid.pr into the 3.10 image (Squeak-dev-114-2) running on the new VM. Did the run spoon.app thing from Spoon.dmg (version 2a12), needs to be done twice if Safari is not running. Got Spoon processor running. Followed instructions again in the Spoon client and lo! Got OtherBrowser browsing the Spoon memory running on processor. Yay Craig! Who do i get to sign my certificate? :) Ken

4 7

normalSend, specialObjectsArray and VM
by Mariano Martinez Peck 03 Oct '10

03 Oct '10

Hi folks. I need to intercept ALL message sends. For the moment, I intercepted in Interpreter >> normalSend But now, I have a question: I know there is that specialObjectArray that contain objects that may be accessed by the VM. So, the first question is, they are only ACCESSED and to things with pointers or they also send messages to those objects from the VM? If the VM really send messages to those object, how that is done ? The code goes also by normalSend ? Or they go from somewhere else that I am not intercepting. Thank you very much. Mariano

7 17

Simulate "3+4" with InterpreterSimulator
by Ang BeePeng 08 Sep '10

08 Sep '10

Hi, I have a InterpreterSimulator start up, in a workspace I type "3+4". From here, I want to step through bytecode per bytecode, when I hit "print". What should I do to achieve this? Can I debug on the interpreter in the middle of the simulation? Or perhaps I need to put a "self halt" somewhere in the VM source? Thanks. Ang Beepeng -- View this message in context: http://n4.nabble.com/Simulate-3-4-with-InterpreterSimulator-tp1678060p16780… Sent from the Squeak - VM mailing list archive at Nabble.com.

5 20

Teleplace Cog VMs are now available
by Eliot Miranda 08 Jul '10

08 Jul '10

Hi All, it gives me great pleasure to announce that the Teleplace Cog VMs are now available. Huge thanks to all at Teleplace who have given me the opportunity to build Cog and release it as open source, been willing guinea pigs braving its bugs, and providing indispensable participation in getting Cog to its current state. Huge thanks are also due to the original Back To The Future team whose VMMaker Cog extends to write the VM, and to Peter Deutsch from whom I've taken many ideas. This release contains two VMs. The Stack VM, is a cross-platform interpreter that uses context-to-stack mapping to achieve modest performance gains. The Cog VM is a just-in-time compiler that currently supports only x86 that builds upon the Stack VM to achieve substantial performance improvements. The release is in the form of a Monticello package containing the VMMaker source and a tarball containing the platform sources, the generated sources and a Squeak 4.1 image containing the VMMaker sources. Download both at http://ftp.squeak.org/Cog/VMMaker-oscog.11.mcz http://ftp.squeak.org/Cog/OpenSourceCog.tar.gz Cog VMs: The Cog VMs are Squeak/Croquet VMs that run closure Squeak/Croquet/Pharo/Cuis images. The VMs support existing plugin source but will require plugins to be recompiled as the VM_PROXY_MAJOR plugin api has been extended. This release contains two distinct VMs, the StackInterpreter and the Cogit. The StackInterpreter is a fully-portable plug-in replacement for the current closure Squeak VMs and images. The Stack VM uses context-to-stack mapping and a somewhat improved garbage collector to achieve modest but useful performance gains in the 10% to 15% range. The StackInterpreter is intended to supersede the Squeak VM on platforms where the Cogit cannot be used. The Cogit extends the StackInterpreter with a just-in-time compiler that uses aggressive inline caching techniques to deliver substantial performance gains in the 3x to 15x range, depending on benchmark. The Cogit currently supports only x86 and the floating-point primitives and parts of the platform support code depend on SSE2. I hope members of the community will attempt to port it, e.g. to ARM, PowerPC and x86-64. The Cogit (excuse the pun) is so named because it is both an interpreter and a JIT, choosing not to generate machine code for large methods, interpreting them instead, the default policy being not to JIT methods with more than 60 literals. The Cog VM requires a few minor image changes all in image/NecessaryImageChangesForCogToWork.1.cs. The JIT's machine-code SmallInteger primitives insist on a SmallInteger receiver so the primitives in LargePositiveInteger = ~= bitAnd: bitOr: butShift: and bitXor: cannot be used and these methods must be deleted. The Cogit inlines the address of the Character instance table, Smalltalk specialObjectsArray at: 25, into the machine-code at: primitive for faster ByteString>>at: and so the table cannot be rebuilt in SmalltalkImage>>recreateSpecialObjectsArray. The new version preserves the existing table. Both VMs maintain floats in platform order to ease implementation of machine code floating-point primitives, and hence internally are in little-endian order instead of big-endian in current Squeak images. While the VMs convert float order automatically on load they do require special accessing primitives Float>>basicAt: & Float>>basicAt:put: that undo the reversal and answer Float contents in big-endian order so that e.g. Float>>hash is unchanged. The methods assume these primitives can fail, allowing the code to be used on current Squeak VMs. The image/VMMaker-Squeak4.1.image is a Squeak 4.1 image, runnable with the current Squeak VMs, that contains these changes, and can hence also be run with a Cog VM. But beware, once an image has been saved on Cog it cannot be run by an existing Squeak VM, because existing VMs cannot undo the Float order change. Platform Subsystem: Most of the platform subsystem is unchanged but there are some important changes that need description. The biggest change is the heartbeat and the clock in platforms/unix/vm/sqUnixHeartbeat.c and platforms/win32/vm/sqWin32Heartbeat.c. The Cog VMs avoid the slow and variable interruptCheckCounter, folding the event check into the stack overflow check on frame build. The heartbeat, typically 500Hz or 1KHz, changes the stackLimit to a value that will always fail. On the next frame building send the VM will enter stack overflow handling that, as a side effect, will also check for events. This is more efficient than the update of interruptCheckCounter and much more regular. If one is running code that executes long-running primitives (e.g. large integer arithmetic) the counter approach will result in too low an interrupt check frequency, and conversely if one is running normal code the interrupt check frequency can be very high. The heartbeat also maintains a 64-bit microsecond clock, UTC microseconds from 1901, from which the backward-compatible millisecond and second clocks are derived. Primitives exist to answer UTC microseconds and local microseconds. Updating the clock in the heartbeat results in a 1 or 2 millisecond resolution but avoids the cost of accessing the OS time on every prim tie which we've found important for performance at Teleplace. The 64-bit microsecond clocks provide a unified time basis and eliminate wrapping (for the next 54,000 years at least). I hope community images will move to these clocks. It's worked well in VisualWorks. Another significant change is in the external semaphore table support code. This is now lock-free at the cost of having to specify a maximum number of external semaphores at start-up (default 256). The support code for the lock-free data structures are processor-specific and is currently implemented only for x86 and gcc-compatible compilers; see platforms/Cross/vm/{sqAtomicOps.h,sqMemoryFence.h}. There is also improved crash reporting code that prints a primitive log and a C backtrace in addition to the Smalltalk backtrace. See platforms/Mac OS/vm/sqMacMain.c, platforms/unix/vm/sqUnixMain.c, platforms/win32/vm/sqWin32Intel.c & platforms/win32/vm/sqWin32Backtrace.c. Finally there is support for the QVMProfiler, a pc-sampling profiler for profiling at the VM level. See platforms/unix/vm/sqUnixVMProfile.c and platforms/win32/vm/sqWin32VMProfile.c. The profiler itself is in the VMMaker image described below in Qwaq-VMProfiling. There are also changes to do with Teleplace-specific extensions to the HostWindowPlugin but these are not essential to Cog. VMMaker and Slang: The image/VMMaker-Squeak4.1.image Squeak 4.1 image contains the complete Cog VMMaker with necessary support code for simulation. This image was used to generate the sources in the src and stacksrc directories. Cog's VMMaker is substantially revised and extended from the current VMMaker. It supports multiple classes, not just Interpreter and superclasses, because both context-to-stack mapping and the Cogit are too complex to write monolithically. Classes can specify ancilliaryClasses and ancilliaryStructClasses, such as CoInterpreterStackPage, CogMethod and CogAbstractInstruction. The Monticello package version is included in the header of all generated files and constitutes the version stamp for generated code. Code is generated in sorted order so that minor changes in the Smalltalk source produce correspondingly minor changes in the generated code. The gnuification step is built-in to VMMaker. No effort has been made to maintain 64-bit compatibility. Apologies, this was unaffordable. The VMMaker generates a single source tree used by all platforms. Instead of deciding at generation time whether to use the Interpreter struct the generated code depends on the SQ_USE_GLOBAL_STRUCT define which can be overridden in platform makefiles. All plugins live in src/plugins and platform makefiles along with plugins.int and plugins.ext files in the build subdirectories decide which plugins are built as external or internal. The VM Generation Workspace from Workspace.text workspace contains dots to generate the sources. We no longer use the VMMakerTool since there should be nothing platform-specific in the generated sources (if we add ports to other ISAs all their source can be included and selected as required by the platform makefiles). Since the Cogit generates x86 machine code simulation is much more complex. There is a support plugin, platforms/Cross/plugins/BochsIA32Plugin that depends on a large simulation of the x86 family implemented in C++ (see processors/IA32/bochs) and on Alien. I use the simulator frequently (but note that I haven't had time to build a working version for Squeak 4.1). I have tested Cog simulation in this image, running on the image/VMMaker-Squeak4.1.image itself. The VM Simulation Workspace in the VMMaker image contains an example doit that starts the simulator. Be patient, even on a fast machine unhibernating the Squeak display background image takes nearly a minute. Native fonts do not (yet) simulate correctly, but the system runs. But note that I have only attempted to build and run the simulator on Mac OS X. I expect Bochs can be built on linux and win32 but I have not tried. By the way, I've not described how to run the Bochs simulator on the current Squeak VM. That's because the plugin depends on the heartbeat to break out of simulation occasionally via a new interpreterProxy entry point setInterruptCheckChain. As this isn't supported by the current Squeak VMs the plugin would require modification. So to simulate first build either of the Cog VMs and then run the simulation with it. There are a number of unpublished changes to the base other than those in NecessaryImageChangesForCogToWork.1.cs. This is partly laziness on my part, partly avoiding publishing things in advance of Cog. These changes are better motivated once Cog is in use. There are changes to the "translated primitives" (see implementors of translatedPrimitives) which replace messages with method tags for generation directives. The Cog VMMaker uses Object>>perform:with:with:with:with: & Object>>perform:with:with:with:with:with: during simulation, and Collection>>#fold: & SquenceableCollection>>#copyUpThrough: during generation. Object>>inline: and Object var:declareC:, which are mispackaged in Kernel in Squeak 4.1 are obsolete (method tags being used instead) and have been removed. I have changed Integer>>hex and Integer>>hex8 back to their original semantics as of 3.8. Backward compatibility is important and one can easily add new selectors if one wants different functionality. VMMaker was here first ;) Tarball: The top-level directories in the tarball are src the tree for the Cog generated sources including all plugins stacksrc/vm the directory containing the Stack VM source (plugins can be taken from above) platforms the usual svn platform tree but including Cog specific changes such as the heartbeat processors the tree containing simulation support code, i.e. the bochs C++ x86 simulation library, along with a potential ARM, PowerPC & MIPS simulator, Skeye. image the Cog-prepared Squeak 4.1 VMMaker image scripts some svn scripts to revert unchanged plugins that haven't really changed cygwinbuild the win32 build directory winbuild the old win32 build directory for minnow gcc 2.95. Not entirely obsolete as the cygwin build as yet fails to generate a functional FFIPlugin macbuild the CoreVM.xcodeproj and support build projects for Mac OS X 10.5 or better unixbuild the build directory for linux Building Cog: Each build directory above contains a HowToBuild file that describes building in more detail. The build directories only contain Cogit makefiles. f you want to build a Stack VM you're on your own but this is very close to the existing Squeak VM build. Status: The Cogit VM has been our sole VM at Teleplace for nearly a year. We do occasionally find bugs and there are almost certainly areas of functionality that we have not touched (for example I know that co-routining does not yet work). If you find a bug please try and create a reproducible test case and let me know. I can't promise to take a look or fix it but I am motivated to do so and will try my best as time allows. Better still if you find and fix bugs be sure to let me know. License (MIT): All contributions from Teleplace in this release are Copyright (c) 2010 Teleplace, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Eliot Miranda June 2010

14 27

Tools to Build Cog on Win32
by Rob Rothwell 01 Jul '10

01 Jul '10

Is there some way to package the tools required to build Cog similar to the Squeak-Win32-Tools package that is available for the standard Squeak VM? I just don't seem to be savvy enough to choose all the proper cygwin options. I DID manage to get subversion loaded in cygwin and check out the sources, but I am sure I am doing the wrong thing by installing the 1.7.5 version of cygwin since HowToBuild references 1.5.24. Plus, I just can't seem to get the right gcc...I keep getting "gcc: The -mno-cygwin flag has been removed; use a mingq-targeted cross-compiler," and I just can't seem to get the right installation options selected in the "Devel" section. So...either a prebuilt bundle or very specific instructions for mere mortals would be very helpful! It would be nice to keep up with the fixes; this VM made a HUGE difference in some Binaural Beat generation code I have that writes very large audio files. I can actually fork the code now and keep using the image with very good responsiveness! Amazing! Thanks for any help, Rob

4 10

Re: [squeak-dev] Very strange bug with Cog VM
by Eliot Miranda 30 Jun '10

30 Jun '10

Hi Stéphane , moving to the VM list... we need to be specific on platforms. I've tested on both Mac and Windows, but not yet on linux. These VMs I've built myself from the svn tree: svn info Path: . URL: http://www.squeakvm.org/svn/squeak/branches/Cog Repository Root: http://www.squeakvm.org/svn/squeak Repository UUID: fa1542d4-bde8-0310-ad64-8ed1123d492a Revision: 2219 Node Kind: directory Schedule: normal Last Changed Author: eliot Last Changed Rev: 2219 Last Changed Date: 2010-06-25 14:32:53 -0700 (Fri, 25 Jun 2010) The build version infos are: (Smalltalk getSystemAttribute: 1006), (String with: Character cr), (Smalltalk getSystemAttribute: 1007), (String with: Character cr), (Smalltalk getSystemAttribute: 1008) 'Mac OS X built on Jun 26 2010 08:21:33 Compiler: 4.2.1 (Apple Inc. build 5659) CoInterpreter VMMaker-oscog.17 uuid: b0ce2f1b-0e18-48d8-a490-4b8ca8476ec7 Jun 27 2010 SimpleStackBasedCogit VMMaker-oscog.16 uuid: f8b8c00f-be77-4358-a537-ac5dd4e27747 Jun 27 2010' 'Win32 built on Jun 27 2010 10:28:30 Compiler: 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) CoInterpreter VMMaker-oscog.17 uuid: b0ce2f1b-0e18-48d8-a490-4b8ca8476ec7 Jun 27 2010 SimpleStackBasedCogit VMMaker-oscog.16 uuid: f8b8c00f-be77-4358-a537-ac5dd4e27747 Jun 27 2010' and for both Mac OS X & Win32 the results in a Squeak4.1 updated from trunk are #('0.0 closeTo: 0' '(1.0 closeTo: 1) and: [0.0 closeTo: 0]' '0.0 closeTo: 0') collect: [:s| Compiler evaluate: s] #(true true true) What's your platform and build info? cheers, Eliot 2010/6/30 Stéphane Rollandin <lecteur(a)zogotounga.net> > #('0.0 closeTo: 0' '(1.0 closeTo: 1) and: [0.0 closeTo: 0]' '0.0 >>> closeTo: 0') collect: [:s| Compiler evaluate: s] #(true true true) >>> >> >> I get #(true false false) in the 4.1 image released as a all-in-one Cog >> zip for Windows by Andreas, on the 20th, which you can get at >> http://squeakvm.org/win32/experimental/CogSqueak4.1.zip >> > > To be as comprehensive as possible in my report: > > I get #(true true true) on that very image with a regular Squeak4.0.2 VM. > > I get #(true false false) either with the Cog VM in the archive or with the > newer VM Levente provided today, based on VMMaker-oscog.17.mcz > > > Stef > > > >

1 0

Squeak 4.1 VM crash
by Rob Withers 29 Jun '10

29 Jun '10

I am running the Cog image on the stock Squeak 4.1 vm. I was testing the Cryptography package. There are two test cases that are now failing: CryptoRigndaelCBCTest>>#testByteArrayFromHexString and CryptoX509Test>>#testSignatureValidation for unknown reasons. I decided to Run Coverage. I am not really sure what this does, but I was trying to find a way to get performance numbers and then compare to the Cog VM. I got the attached crash dump. Rob

3 28

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2010