Nabble - Squeak vm-dev

Re: A gprof listing of memory access functions in the interpreter

2008-07-21T04:55:20Z

On Sun, Jul 20, 2008 at 11:49 PM, David T. Lewis <lewis@...> wrote:

I don't know if this is of any general interest, but attached is a
gprof output listing of a Squeak VM with the memory access routines
from sqMemoryAccess.h recoded in Slang.

I now have the Slang inlining working so that it can fully inline all
of these methods. With the Slang inlining activiated, performance is
essentially identical to that of the normal macros in sqMemoryAccess.h.
By turning the Slang inlining off, the functions are all called
individually, which is what I used to generated the attached profile.

The host is 64-bit Linux AMD. The profile was run by opening a largish
image, running "0 tinyBenchmarks" a half dozen times, and exiting the
image without saving.

So far, the advantages of putting the memory access routines into
the image as Slang seem to be:
- You can step into the methods in a debugger
- The methods can be profiled
- Exposes type declaration problems previously hidden by the macros

Is anyone interested in this?

Dave

Yeah, I'm interested in this. I'm always interested in speeding up the interpreter.

What I find interesting is that there's no particular hot spot in the profile. I find
that profiling typically reveals a single function taking up 50+% of the runtime,
but that isn't the case here. There's a fairly even tail.

Even if we *doubled* the speed of interpret() and pointerForOop(), we'd still
only gain a 20% speed-up.

So there's isn't any easy improvement, unless I misunderstand the data
(which is quite possible!). To gain significant speed-ups, we'd have to make
hundreds of micro-optimisations throughout the code-base, which would
probably complicate the code (which is pretty clean at the moment).

Andrew

Re: New plugin support

2008-07-21T03:37:03Z

El mar, 22-04-2008 a las 09:05 -0700, Ian Piumarta escribió:

> Hi,
>
> I'm about to commit (add) cross-platform directories to support
> GStreamerPlugin and OggPlugin. If anyone thinks this is a bad idea,
> please speak now.
>
> (FYI: the unix tree will also be getting ClipboardExtendedPlugin,
> DBusPlugin, RomePlugin and ImmX11Plugin in the same commit.)
>
> Cheers,
> Ian
>

Ian, you haven't commited these directories yet, any problem with it?
Without them the unix tree can not compile these plugins.

signature.asc (204 bytes) Download Attachment

A gprof listing of memory access functions in the interpreter

2008-07-20T14:49:28Z

I don't know if this is of any general interest, but attached is a
gprof output listing of a Squeak VM with the memory access routines
from sqMemoryAccess.h recoded in Slang.

I now have the Slang inlining working so that it can fully inline all
of these methods. With the Slang inlining activiated, performance is
essentially identical to that of the normal macros in sqMemoryAccess.h.
By turning the Slang inlining off, the functions are all called
individually, which is what I used to generated the attached profile.

The host is 64-bit Linux AMD. The profile was run by opening a largish
image, running "0 tinyBenchmarks" a half dozen times, and exiting the
image without saving.

So far, the advantages of putting the memory access routines into
the image as Slang seem to be:
- You can step into the methods in a debugger
- The methods can be profiled
- Exposes type declaration problems previously hidden by the macros

Is anyone interested in this?

Dave

gprof.out.gz (49K) Download Attachment

Re: Profiling with gprof

2008-07-19T11:08:06Z

On Sat, Jul 19, 2008 at 07:00:29PM +0200, Andr?? Wendt wrote:
>
> Hi,
>
> has anyone successfully profiled the VM with gprof lately, preferably on
> Linux? If so, how did you do it?
>
> I've tried the hints at http://wiki.squeak.org/squeak/2041 but I guess
> they're badly out of date: configure and GCC 4.2 will choke on '-g -pg
> -a' but not '-g -pg', and so there's no bb.out.

I just hand-edit ./Makefile and ./vm/Makefile in the build directory, and
add "pg" to the CFLAGS definition of each. The resulting VM produces a
gmon.out file, and running "gprof ./squeak" provides the profiling output.
This is on Linux, and I just went by the information in the gprof(1) man
page.

Dave

Re: X11 HostWindowPlugin (was: Re: ioGetWindowLabel/ioSetWindowLabel (was Re: How to use Croquet VMMaker)

2008-07-19T10:58:23Z

On Sat, Jul 19, 2008 at 08:33:17AM -0700, tim Rowledge wrote:
>
> On 19-Jul-08, at 7:28 AM, David T. Lewis wrote:
> > MIT license of course, and the plagiarized parts
> >should be MIT because I stole them all from Ian ;)
> Ah, so it's 'My Ideas Taken'. I always wondered about that :-)

Oh dear, I thought it was "My Implementation Taken" which is why I felt
at liberty to engage in outright plagiarism. If the license permits only
the plunder of ideas, I may have inadvertently exceeded its boundaries.
Next time I'll consult a lawyer before taking unnecessary risks ;)

Dave

Profiling with gprof

2008-07-19T10:00:29Z

Hi,

has anyone successfully profiled the VM with gprof lately, preferably on
Linux? If so, how did you do it?

I've tried the hints at http://wiki.squeak.org/squeak/2041 but I guess
they're badly out of date: configure and GCC 4.2 will choke on '-g -pg
-a' but not '-g -pg', and so there's no bb.out.

What's worse is that gprof doesn't produce any statistics apart from
vm/sqUnixMain.c -- here's its summary:

Top 10 Lines:

Line Count

239 1
934 1
977 1
1134 1
1159 1
1166 1
1279 1

What the... ? Hello, I was hoping for some details on the interpret()
function!? -- Well, what more can possibly be in 430 KB of gmon.out? ;-)

So how do I get gprof to take note of interp.c or gnu-interp.c?

Thanks,
André

Re: X11 HostWindowPlugin (was: Re: ioGetWindowLabel/ioSetWindowLabel (was Re: How to use Croquet VMMaker)

2008-07-19T08:33:17Z

On 19-Jul-08, at 7:28 AM, David T. Lewis wrote:
> MIT license of course, and the plagiarized parts
> should be MIT because I stole them all from Ian ;)
Ah, so it's 'My Ideas Taken'. I always wondered about that :-)

tim
--
tim Rowledge; tim@...; http://www.rowledge.org/tim
Strange OpCodes: CSD: Charge Surreptitiously to DOE

X11 HostWindowPlugin (was: Re: ioGetWindowLabel/ioSetWindowLabel (was Re: How to use Croquet VMMaker)

2008-07-19T07:28:13Z

Bert,

Here is a snapshot of a partially implemented HostWindowPlugin
for X11. I have not looked at this in quite a while, but when
I last worked on it a number of things were functional (including
ioSetTitleOfWindow(), for whatever that may be worth).

Some of the support code is crudely hacked out of Ian's original
work, and I would anticipate some effort to make this right. In
particular, it was not clear to me how the X event dispatching
should ultimately work, and whether the host windows should behave
analogously to Squeak projects or if they were intended to be
more like passive display surfaces.

I could probably be motivated to pick this up again and/or to
help you with it, but in any case feel free to use this in any
way you like. MIT license of course, and the plagiarized parts
should be MIT because I stole them all from Ian ;)

Dave

On Fri, Jul 18, 2008 at 06:53:29PM -0700, Bert Freudenberg wrote:

>
> Am 05.02.2008 um 02:11 schrieb Bert Freudenberg:
>
> >On Feb 5, 2008, at 8:15 , Andreas Raab wrote:
> >
> >>ioGetWindowLabel/ioSetWindowLabel
> >>
> >>These are support functions that are currently not implemented in
> >>the Unix/Mac VMs (we use them to get/set the main window title
> >>directly). Here is how to stub them (best done in sqUnixMain.c):
> >>
> >>char* ioGetWindowLabel(void) {return "";}
> >>sqInt ioSetWindowLabelOfSize(void* lbl, sqInt size) {return 0;}
> >>
> >>This should do the trick.
> >
> >Actually, I need to implement these for X11 anyway. Expect this to
> >soon be supported in the OLPC branch. Unless someone beats me to it
> >of course :)
>
>
> Hmm, where could I find the code calling this? I'd need both the slang
> and image-side code.
>
> - Bert -
>

X11HostWindowPlugin-dtl.1.cs.gz (1K) Download Attachment
X11HostWindow.tgz (94K) Download Attachment

Re: ioGetWindowLabel/ioSetWindowLabel (was Re: How to use Croquet VMMaker)

2008-07-18T18:53:29Z

Am 05.02.2008 um 02:11 schrieb Bert Freudenberg:

> On Feb 5, 2008, at 8:15 , Andreas Raab wrote:
>
>> ioGetWindowLabel/ioSetWindowLabel
>>
>> These are support functions that are currently not implemented in
>> the Unix/Mac VMs (we use them to get/set the main window title
>> directly). Here is how to stub them (best done in sqUnixMain.c):
>>
>> char* ioGetWindowLabel(void) {return "";}
>> sqInt ioSetWindowLabelOfSize(void* lbl, sqInt size) {return 0;}
>>
>> This should do the trick.
>
> Actually, I need to implement these for X11 anyway. Expect this to
> soon be supported in the OLPC branch. Unless someone beats me to it
> of course :)

Hmm, where could I find the code calling this? I'd need both the slang
and image-side code.

- Bert -

Re: Events handling for SqueakGtk

2008-07-13T01:46:44Z

Hi!

Note that already the original (before Luca Bruno's work on it)
SqueakGtk included code for this mechanism. It even queued the events on
the plugin side.

regards, Göran

David T. Lewis wrote:

>
> On Fri, Jul 11, 2008 at 01:30:43PM +0200, Bert Freudenberg wrote:
>>> To solve this problem I'll create a C thread and say to the vm
>>> change the status of the current process
>>> call the blocking method and when there is an event wake up the
>>> process to say I've finished my work.
>>>
>>> Is there a way to solve this problem ?
>>
>> The canonical way to do this is have the Smalltalk process wait on a
>> Semaphore, and signal that Semaphore from the VM if there is anything
>> to do. See senders of "Smalltalk registerExternalObject:
>> someSemaphore" for examples.
>
> The SocketPlugin uses this technique, and you can find additional examples
> in AioPlugin (notify a Smalltalk process on IO activity) and OSProcessPlugin
> (notify a Smalltalk process on termination of an external process). These
> are on SqueakMap/SqueakSource.
>
> Dave
>

Re: Events handling for SqueakGtk

2008-07-12T04:59:03Z

On Fri, Jul 11, 2008 at 01:30:43PM +0200, Bert Freudenberg wrote:

> >To solve this problem I'll create a C thread and say to the vm
> >change the status of the current process
> >call the blocking method and when there is an event wake up the
> >process to say I've finished my work.
> >
> >Is there a way to solve this problem ?
>
>
> The canonical way to do this is have the Smalltalk process wait on a
> Semaphore, and signal that Semaphore from the VM if there is anything
> to do. See senders of "Smalltalk registerExternalObject:
> someSemaphore" for examples.

The SocketPlugin uses this technique, and you can find additional examples
in AioPlugin (notify a Smalltalk process on IO activity) and OSProcessPlugin
(notify a Smalltalk process on termination of an external process). These
are on SqueakMap/SqueakSource.

Dave

Re: Events handling for SqueakGtk

2008-07-11T04:48:24Z

On 11 Jul 2008, at 13:30, Bert Freudenberg wrote:

>
> Am 11.07.2008 um 13:26 schrieb Gwenael Casaccio:
>
>> Hello,
>>
>> I am the student who is working for the SqueakGtk plugin and I have
>> a small problem.
>> For the events handling there is an *active waiting system* like
>> this :
>>
>>
>> mainLoopProcess := [
>> [
>> [self doMainIteration.
>> self doSignalProcessing] forkAt: Processor
>> userBackgroundPriority + 1
>> ] repeat
>> ] forkAt: Processor userBackgroundPriority
>>
>>
>> It consumes a lot of cpu time.
>> the problem is the method doMainIteration which call a C method to
>> get an hypothetic event,
>> I would like to replace this C method by an other method but this
>> new method will block the interpreter
>> until there is an event.
>>
>> To solve this problem I'll create a C thread and say to the vm
>> change the status of the current process
>> call the blocking method and when there is an event wake up the
>> process to say I've finished my work.
>>
>> Is there a way to solve this problem ?
>
>
> The canonical way to do this is have the Smalltalk process wait on a
> Semaphore, and signal that Semaphore from the VM if there is
> anything to do. See senders of "Smalltalk registerExternalObject:
> someSemaphore" for examples.
>
> - Bert -
>
>

Thanks for you answer !

Gwenael

Re: Events handling for SqueakGtk

2008-07-11T04:30:43Z

Am 11.07.2008 um 13:26 schrieb Gwenael Casaccio:

> Hello,
>
> I am the student who is working for the SqueakGtk plugin and I have
> a small problem.
> For the events handling there is an *active waiting system* like
> this :
>
>
> mainLoopProcess := [
> [
> [self doMainIteration.
> self doSignalProcessing] forkAt: Processor userBackgroundPriority
> + 1
> ] repeat
> ] forkAt: Processor userBackgroundPriority
>
>
> It consumes a lot of cpu time.
> the problem is the method doMainIteration which call a C method to
> get an hypothetic event,
> I would like to replace this C method by an other method but this
> new method will block the interpreter
> until there is an event.
>
> To solve this problem I'll create a C thread and say to the vm
> change the status of the current process
> call the blocking method and when there is an event wake up the
> process to say I've finished my work.
>
> Is there a way to solve this problem ?

The canonical way to do this is have the Smalltalk process wait on a
Semaphore, and signal that Semaphore from the VM if there is anything
to do. See senders of "Smalltalk registerExternalObject:
someSemaphore" for examples.

- Bert -

Events handling for SqueakGtk

2008-07-11T04:26:52Z

Hello,

I am the student who is working for the SqueakGtk plugin and I have a
small problem.
For the events handling there is an *active waiting system* like this :

mainLoopProcess := [
[
[self doMainIteration.
self doSignalProcessing] forkAt: Processor userBackgroundPriority + 1
] repeat
] forkAt: Processor userBackgroundPriority

It consumes a lot of cpu time.
the problem is the method doMainIteration which call a C method to
get an hypothetic event,
I would like to replace this C method by an other method but this new
method will block the interpreter
until there is an event.

To solve this problem I'll create a C thread and say to the vm change
the status of the current process
call the blocking method and when there is an event wake up the
process to say I've finished my work.

Is there a way to solve this problem ?

Cheers,
Gwenael

Re: Mac OS - path and file name of the VM app

2008-07-09T16:14:33Z

Nice, thank you very much!

On Jul 9, 2008, at 11:40 PM, Andreas Raab wrote:

>
> Hi Robert -
>
> If I remember correctly this does the trick:
>
> Smalltalk getSystemAttribute: 0.
>
> Cheers,
> - Andreas

Re: Mac OS - path and file name of the VM app

2008-07-09T14:40:34Z

Hi Robert -

If I remember correctly this does the trick:

Smalltalk getSystemAttribute: 0.

Cheers,
- Andreas

Robert Krahn wrote:

>
> Hi!
>
> I am trying to create a sar file which moves a .bundle directory into
> the VM app. Let's assume that my SqueakVM is /Applications/SqueakVM.app.
> Then I would have to move my bundle directory into
> /Applications/SqueakVM.app/Contents/Resources/.
>
> I get the path to the vm app with SmalltalkImage current vmPath. But
> this only evaluates to /Applications/. How do I get the name of the app
> directory?
>
> Thanks,
> Robert
>

Re: Mac OS - path and file name of the VM app

2008-07-09T14:29:31Z

Robert Krahn wrote:

Which is actually the correct behavior, as the .app is the vm as far as
external appearance is concerned.
Did you try imagePath? You could also have a look at the Sophie File
Locations package.

Michael

Mac OS - path and file name of the VM app

2008-07-09T03:51:01Z

Hi!

I am trying to create a sar file which moves a .bundle directory into
the VM app. Let's assume that my SqueakVM is /Applications/
SqueakVM.app. Then I would have to move my bundle directory into /
Applications/SqueakVM.app/Contents/Resources/.

I get the path to the vm app with SmalltalkImage current vmPath. But
this only evaluates to /Applications/. How do I get the name of the
app directory?

Thanks,
Robert

MemoryAccess

2008-07-07T03:43:39Z

FYI, repeating from recent discussions on squeak-dev list:

Over the last 2 weeks I've been playing around with replacing the memory
access macros in sqMemoryAccess.h with equivalent Smalltalk slang. Along
the way I found and fixed several slang issues that prevented inlining of
methods with C declarations. I posted a snapshot of this on squeak-dev in
response to a question there, so I'm mentioning here on vm-dev for the
record.

I have the memory access methods working now, and with all the slang
inlining applied I'm seeing about 20% of the performance of the interpreter
using C macros. I don't know if it will be possible or practical to
achieve the performance of the CPP macros, but it does seem useful to
be able to generate the VM entirely in C without macros as an aid to
debugging and possibly profiling

The slang translation bug fixes will be worth capturing on Mantis, and
I'll do so within the next couple of weeks.

The thread on squeak-dev, including the change sets, is here:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-July/129982.html

Dave

[Squeak-fr] Master 'Software for embedded systems' -- Master Systèmes Embarqués à Brest - France

2008-07-03T07:16:43Z

(sorry for the multiple copies)

University of Brest (UBO) plans to open two new Master of Sciences automn 2008:

   'LSE : Logiciel pour les Systèmes Embarqués'
   (Software for embedded systems)

   'iMARS : Microtechnologies, Architecture, Réseaux et Systèmes de communications'
   (Microtechnologies, Architecture, Networks and communication systems)

LSE and iMARS include one course in object oriented programming and methods that
covers advanced topics teached on Smalltalk-80 platforms with in mind architectural support
of execution, code and hardware synthesis.

This course is given by a research group (*) developing tools (circuit and system
level) in relation with innovative projects such as reconfigurable system on chips
and non-CMOS emergent technologies (lot of Smalltalk programming on hot topics!).

Master LSE is a computer science curriculum.
Flyer : http://as.univ-brest.fr/flyer_master_fr.pdf
student application and program : http://dept-info.univ-brest.fr/pages/master-systeme-embarque.htm
contact: pottier at univ - brest . fr

Master iMARS is a regional merge of electronics/communication and CS curricula:
http://www.insa-rennes.fr/master2-imars
contact: Noel . Tanguy at univ - brest . fr

(*) Architectures et Systemes, LabSTICC, UMR CNRS 3192

_______________________________________________
Squeak-fr mailing list
Squeak-fr@...
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-fr

--
Damien Picard

Re: Socket listening

2008-07-01T08:11:21Z

Am 01.07.2008 um 17:03 schrieb Ian Piumarta:

> Hi Bert,
>
> On Jul 1, 2008, at 6:35 AM, Bert Freudenberg wrote:
>
>> which means the second socket listens successfully, but on a random
>> port. I verified it is actually listening there using lsof. The
>> SO_REUSEADDR option does not make any difference, btw.
>>
>> I think I should not rely on it. Also, the same code gives an error
>> (as expected) on Windows.
>
> The behaviour you're seeing seems broken to me; bind() should fail
> if another socket is already bound to the same listening address.
> I'll take a look.

In the mean time I found that the new SocketAddressInfo-based code
actually gives an error when binding, as expected. Only the old
primitiveSocketListenWithOrWithoutBacklog silently binds to a random
port.

- Bert -

Re: Socket listening

2008-07-01T08:03:59Z

Hi Bert,

On Jul 1, 2008, at 6:35 AM, Bert Freudenberg wrote:

> which means the second socket listens successfully, but on a random
> port. I verified it is actually listening there using lsof. The
> SO_REUSEADDR option does not make any difference, btw.
>
> I think I should not rely on it. Also, the same code gives an error
> (as expected) on Windows.

The behaviour you're seeing seems broken to me; bind() should fail if
another socket is already bound to the same listening address. I'll
take a look.

Cheers,
Ian

Socket listening

2008-07-01T06:35:23Z

Ian, and folks,

I'm trying to write a more robust Etoys server for OLPC, and found
some surprising listening behavior.

The snippet below tries to listen on the same port twice. I'd have
expected to get an error on the second listening attempt. However, on
both Linux and Mac OS X (John's VM) I get back

#(6060 57855)

which means the second socket listens successfully, but on a random
port. I verified it is actually listening there using lsof. The
SO_REUSEADDR option does not make any difference, btw.

So, is this intended behavior? If not, will we change it?

In my actual use case I would have tried to iterate through some ports
to find an unbound one, so in this particular case the behavior is
convenient for me. But I think I should not rely on it. Also, the same
code gives an error (as expected) on Windows.

- Bert -

[
p := 6060.

s1 := Socket newTCP.
s1 setOption: 'SO_REUSEADDR' value: 0.
s1 listenOn: p.

s2 := Socket newTCP.
s2 setOption: 'SO_REUSEADDR' value: 0.
s2 listenOn: p.

{
s1 isValid ifTrue: [s1 port].
s2 isValid ifTrue: [s2 port]
}
] ensure: [
s1 destroy.
s2 destroy.
]

Mantis 5238 questions

2008-06-23T22:11:53Z

Neither Dave nor I particularly like the 'solution' in 5238. Does
anyone else have cleaner solutions to offer?

tim
--
tim Rowledge; tim@...; http://www.rowledge.org/tim
Strange OpCodes: PIC: Permute Instruction Codes

Building 3.10-1 on freebsd

2008-06-20T11:37:17Z

I'm getting this error

In function `sqLocDaylightSavings':
/usr/home/rh/squeak/Squeak-3.10-1/platforms/unix/plugins/LocalePlugin/sqUnixLocale.c:674:
undefined reference to `daylight'

while trying to build the vm on a freebsd7.0/i386, gcc 4.2.1 machine. I
can work easily around it by changing the sqLocDaylightSavings function to
always return zero but it baffles me why such simple construct doesn't
work.

After I install it, squeak won't run because it can't find the display
driver "vm-display-X11.so" - the installed file is named
"libvm-display-X11.0.0". Same for sound driver. Symlinking to proper names
allows Squeak to run

What should I do with me newly acquired wisdom? Report on mantis?

Regards, radoslav

CfP: 2nd International Workshop on Virtual Machines and Intermediate Languages for Emerging Modularization Mechanisms (VMIL 2008)

2008-06-19T04:14:39Z

Second international workshop on Virtual Machines and Intermediate
Languages for emerging modularization mechanisms (VMIL 2008) - a
one-day workshop affiliated with OOPSLA 2008.

http://www.cs.iastate.edu/~design/vmil/

Submission URL: http://www.easychair.org/conferences/?conf=VMIL-08

Important Dates
Submission Deadline: Aug 4, 2008, 23:59 Samoan
Notification of Acceptance: Sept 4, 2008
Camera ready copy due: Oct 1, 2008
Workshop: Oct 19, 2008

Program Committee

* Eric Bodden (McGill University, Canada)
* Juan Chen (Microsoft Research, USA)
* Shigeru Chiba (Tokyo Institute of Technology, Japan)
* Sophia Drossopoulou (Imperial College, UK)
* Eric Eide (University of Utah, USA)
* Matthew Flatt (University of Utah, USA)
* Gregor Kiczales (University of British Columbia, Canada)
* Hidehiko Masuhara (University of Tokyo, Japan)
* Greg Morrisett (Harvard University, USA)
* Angela Nicoara (ETH Zurich, Switzerland)
* Harold Ossher (IBM Research, USA)
* and the organizers

Organizers
* Hridesh Rajan, (Iowa State University, USA)
* Christoph Bockisch, (Darmstadt University of Technology)
* Michael Haupt (Hasso Plattner Institute, University of Potsdam, Germany)
* Robert Dyer (Iowa State University, USA)

Motivation and Objectives

Modern programming languages are compiled to intermediate code
preserving the intention of high-level language constructs. Emerging
modularization mechanisms, however, lack such handling. Recent
research results have shown that deeper support for these
modularization mechanisms, e.g., in virtual machines and intermediate
languages, is feasible; it allows applying tailored optimizations and
radically improves development processes such as incremental
compilation, debugging, etc.

The VMIL workshop, second in the series, is a forum for research in
virtual machines and intermediate languages with support for emerging
modularization mechanisms such as mix-ins, units, open classes,
hyper-slices, adaptive methods, roles, composition filters, layers,
pointcuts-and-advice, and inter-type declarations. Topics of interest
include, but are not limited to: compilation-based and
interpreter-based virtual machines as well as intermediate language
designs with dedicated support for emerging modularization mechanisms,
compilation techniques, optimization strategies, improved techniques
for fast predicate evaluation (e.g., of pointcuts) inside virtual
machines, and advanced caching and memory management schemes.

The areas of interest include, but are not limited to:
compilation-based and interpreter-based virtual machine as well as
intermediate language designs that better support these emerging
modularization mechanisms, intermediate language constructs that
better support these modularization mechanisms, compilation techniques
from high-level languages to enhanced intermediate languages,
optimization strategies for reduction of runtime overhead due to
either compilation or interpretation, improved techniques for fast
evaluation of pointcuts and other predicates inside virtual machines,
use cases for deeper support in the virtual machines and intermediate
languages, advanced caching and memory management schemes in support
of the mechanisms.

Paper Categories

In these key areas, we invite high-quality papers in the following two
categories.

* Research and experience papers: These submissions should describe
work that advances the current state of the art in support of advanced
separation of concerns techniques in virtual machines and intermediate
languages. Experience papers that are of broader interest and describe
insights gained from practical applications. The page limit for these
submissions is 10 pages.

* Position papers: These submissions present and defend the author/s
position on a topic related to the broader area of the workshop. The
page limit for these submissions is 6 pages.

Review Process

The program committee will evaluate each paper based on its relevance,
significance, clarity and originality. Each submission will be
reviewed by at least three PC members.

Paper Submission

Papers should be submitted in PDF format at the submission URL
http://www.easychair.org/conferences/?conf=VMIL-08. The results
described must
be unpublished and must not be under review for another workshop,
conference or journal. Submissions must conform to ACM SIGPLAN format
and must not exceed the page limit of the category in which it is
classified by authors (including all text, figures, references and
appendices). Submissions which do not conform to this will be desk
rejected without reviews.

Re: Re: [squeak-dev] Re: Bug in object finalization?

2008-06-18T17:42:37Z

On 18-Jun-08, at 4:22 PM, John M McIntosh wrote:

Well the *real* issue here is that VM level fixes just aren't properly tracked and place in the VM or NOT placed in the VM. The process I'm afraid just relies on too many
folks remembering to check the bugs, acting on email flows to the vm-dev list or squeak list.

Well there is Mantis; currently I have 16 reports open, some of which are suspended pending answers or information from other people.

For example, 6669 is waiting on info from Andreas

6828 is waiting on answers from anyone interested (see [Vm-dev] Mantis http://bugs.squeak.org/view.php?id=6828)

5228 is waiting on response from Ron

5236 is waiting on response from Andreas and/or Eliot (though mantis claims I sent a reminder to 'iho' whoever that might be!)

7022 is waiting on a response from St. Expedite or St. Isidore (http://www.wired.com/culture/lifestyle/news/2004/11/65184)

6966 is waiting on repsonse from kbrown and/or jmm

What I would propose is say a monthly or even quarterly meeting/mailing? to co-ordinate the process to a better degree to ensure yes or no this fix is going into the VM.

Yes, something like that would be nice. Of course, a large part of the problem has been that I've been busy for the last while and unable to pay much attention, for which I must apologise. Right now I'm trying to catch up and get things into a good enough state to make it sensible to run a more open repository for VMMaker. Getting answers from the above mentioned people would be a big help.

tim

tim Rowledge; tim@...; http://www.rowledge.org/tim

Strange OpCodes: APX: Apply Power and eXplode

Re: [squeak-dev] Re: Bug in object finalization?

2008-06-18T16:22:07Z

Well the *real* issue here is that VM level fixes just aren't properly
tracked and place in the VM or NOT placed in the VM. The process I'm
afraid just relies on too many
folks remembering to check the bugs, acting on email flows to the vm-
dev list or squeak list.

What I would propose is say a monthly or even quarterly meeting/
mailing? to co-ordinate the process to a better degree to ensure yes
or no this fix is going into the VM.

On Jun 18, 2008, at 2:44 PM, Andreas Raab wrote:

> nicolas cellier wrote:
>> Dilbert Dogbert a écrit :
>>> Andreas Raab wrote:
>>>> No - we've fixed this a long time ago in our code base.
>>>
>>> Thanks for not sharing
>>>
>> Can't speak for Andreas, but would i be asked so kindly that i'm
>> not sure i would be more inclined to share.
>
> Oh don't worry I'm pretty thick-skinned. The only disappointing part
> is that the above poster (who happens to be a well-renowned member
> of the Squeak community btw) thinks that I wouldn't instantly
> recognize his style. I mean "Dilbert Dogbert"? Come on, you might
> have just as well signed with your real name ;-)
>
>> Let's be more positive!
>> Thanks for taking time to share in squeak-dev finally.
>
> You're welcome. Interestingly, the exchange that sparked this fix
> included both Tim and John. Seems like they didn't consider this to
> be uber-critical either.
>
> Cheers,
> - Andreas
>

--
=
=
=
========================================================================
John M. McIntosh <johnmci@...>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================

Re: Mantis bug 215, JPEG plugin problems on Sparc

2008-05-28T02:57:34Z

On Tue, May 27, 2008 at 9:45 PM, tim Rowledge <tim@...> wrote:

Does anyone care enough about this to spend time on it? Are there any running Sparc systems left?

See http://bugs.squeak.org/view.php?id=215

Yeah, I run on Solaris/SPARC. I'll take a look when I get a chance. Actually, this problem is likely to affect all non-x86 platforms, since most (all?) of them require alignment. So it's worth fixing.

While on the subject, my patches to get sound working on Solaris never got merged. There wasn't any explanation -- if they weren't of good enough quality, I'd like to have known, so I could sort out the problem. Anyone?

Andrew

Re: VMMaker updating: Mantis 6828 and the future of copying files

2008-05-27T15:09:26Z

At 2:47 PM -0700 5/27/08, Andreas Raab apparently wrote:

>Ken G. Brown wrote:
>>I'm talking about moving forward with continuous incremental improvement when there is a chance to easily do so.
>
>The emphasis being on "easily". It's not. It requires all the images that want to use the VMs to update their code base to use the corresponding names.
>
>>Kinda like entering a race and intentionally trying for only second place.
>
>More like avoiding the race completely since there is absolutely nothing to be won in it.
>
>Cheers,
> - Andreas

Well, then say that the newly generated VM's from the new improved VMMaker work with new improved images. And if you want the older images to work, make a couple of minor changes. All in the name of incremental improvement thereby reducing confusion for the way forward.

Ken G. Brown

Re: VMMaker updating: Mantis 6828 and the future of copying files

2008-05-27T14:47:20Z

Ken G. Brown wrote:
> I'm talking about moving forward with continuous incremental improvement when there is a chance to easily do so.

The emphasis being on "easily". It's not. It requires all the images
that want to use the VMs to update their code base to use the
corresponding names.

> Kinda like entering a race and intentionally trying for only second place.

More like avoiding the race completely since there is absolutely nothing
to be won in it.

Cheers,
- Andreas

Re: VMMaker updating: Mantis 6828 and the future of copying files

2008-05-27T14:12:43Z

At 1:27 PM -0700 5/27/08, Andreas Raab apparently wrote:

>Ken G. Brown wrote:
>>I have found at least:
>>
>>internal plugin B3DEnginePlugin generated as Squeak3D
>>internal plugin BalloonEnginePlugin generated as B2DPlugin
>>internal plugin BitBltSimulation generated as BitBltPlugin
>>internal plugin DSAPlugin generated as DSAPrims
>>internal plugin DeflatePlugin generated as ZipPlugin
>>internal plugin FFIPlugin generated as SqueakFFIPrims
>>internal plugin KlattSynthesizerPlugin generated as Klatt
>>internal plugin LargeIntegersPlugin generated as LargeIntegers
>>
>>Very confusing.
>
>But necessary to keep existing code running.
>
>Cheers,
> - Andreas

I'm talking about moving forward with continuous incremental improvement when there is a chance to easily do so.
Those that need to stay in the past can easily do so and avoid using the new stuff, otherwise do the simple change to use the new.

I feel that if you always make compromises in the direction of backward compatibility, the quality of the way forward is also compromised.

Kinda like entering a race and intentionally trying for only second place.

Ken G. Brown

Re: VMMaker updating: Mantis 6828 and the future of copying files

2008-05-27T13:54:22Z

On 27-May-08, at 12:54 PM, Bert Freudenberg wrote:

> On 27.05.2008, at 20:33, tim Rowledge wrote:
>
>> OK, two issues here, one shortterm, one longer term.
>>
>> a) in mantis 6828 Dave Lewis proposes some changes to fix some
>> 64bitness issues. They look good to me and he added tests. However
>> I'm not responsible for unix vms and I'm not about to commit those
>> changes. Somebody else will have to handle that and close the
>> mantis report etc.
>
> Ian added Dave's VMMaker patches already, so I assume he'd merge
> these things, too. OTOH if we were to drop the FileCopyPlugin, we
> would not need to update it, right?

Correct but I don't see us getting all the work to add links etc done
any time soon and so the old plugin needs to work.

>
>
>> b) I'm reasonably sure that all the platforms we are interested in
>> now support file links of some sort. File copying (and the vile
>> FileCopyPlugin may it be cursed to the bottom of the pits of Vista)
>> was only ever used because we had no linking available. Eliot will
>> cheerfully (I'm sure) rabbit on for hours about how we used to
>> handle things in the brouhaha source tree, where sets of files for
>> particular platforms were assembled by links from the assorted
>> subsystems, thus making it easy to make. Or even nmake.
>> It would be really nice to agree a path towards a brighter future
>> where VMMaker doesn't have to copy files and worry about damned
>> permissions/attributes/flavours/whatever. Thoughts please?
>
>
> Bury it I'd say. Who was using it anyway?

It's been a while since I thought about this stuff. IIRC the copying
was originally intended to allow the assembly of a customised
directory so that the automake stuff could then create the right VM
based on the list of plugins etc that were in the directory. It might
have been possible to write out a config file for automake as an
alternative but then you'd have to do something similar for nmake
(what was in use for windows at the time) and CodeWorrier (what was in
use for Macs) and so on. Things are quite a lot different these days
and maybe we should try to take advantage of any improvements over the
last 10 years.

Part of the complication was that people wanted to be able to make
custom combinations of internal and external plugins. I doubt that has
been used all that much. Personally I think that all plugins should be
external and that the platform should have a sensible way of coping
with that.

>
> Btw, I think it would be nice to revive
>
> http://www.squeaksource.com/VMMaker.html

Yes, it would.

> Also, some idea about how to handle plugins development-wise would
> be nice. The unix VM now ships several non-default plugins (DBus,
> GStreamer, Rome, maybe more) that one has to download from different
> repositories. Maybe the source for those should be added to the
> VMMaker repo? Or added to SVN? Maybe even a whole VMMaker image?

I don't know how we should handle plugins that need code from other
projects. Suggestions welcome.

tim
--
tim Rowledge; tim@...; http://www.rowledge.org/tim
"Bother" said Pooh, as the Vice Squad took his GIFS ..

Re: VMMaker updating: Mantis 6828 and the future of copying files

2008-05-27T13:27:16Z

Ken G. Brown wrote:

> I have found at least:
>
> internal plugin B3DEnginePlugin generated as Squeak3D
> internal plugin BalloonEnginePlugin generated as B2DPlugin
> internal plugin BitBltSimulation generated as BitBltPlugin
> internal plugin DSAPlugin generated as DSAPrims
> internal plugin DeflatePlugin generated as ZipPlugin
> internal plugin FFIPlugin generated as SqueakFFIPrims
> internal plugin KlattSynthesizerPlugin generated as Klatt
> internal plugin LargeIntegersPlugin generated as LargeIntegers
>
> Very confusing.

But necessary to keep existing code running.

Cheers,
- Andreas

Re: VMMaker updating: Mantis 6828 and the future of copying files

2008-05-27T13:18:50Z

At 9:54 PM +0200 5/27/08, Bert Freudenberg apparently wrote:

>On 27.05.2008, at 20:33, tim Rowledge wrote:
>
>>OK, two issues here, one shortterm, one longer term.
>>
>>a) in mantis 6828 Dave Lewis proposes some changes to fix some 64bitness issues. They look good to me and he added tests. However I'm not responsible for unix vms and I'm not about to commit those changes. Somebody else will have to handle that and close the mantis report etc.
>
>Ian added Dave's VMMaker patches already, so I assume he'd merge these things, too. OTOH if we were to drop the FileCopyPlugin, we would not need to update it, right?
>
>>b) I'm reasonably sure that all the platforms we are interested in now support file links of some sort. File copying (and the vile FileCopyPlugin may it be cursed to the bottom of the pits of Vista) was only ever used because we had no linking available. Eliot will cheerfully (I'm sure) rabbit on for hours about how we used to handle things in the brouhaha source tree, where sets of files for particular platforms were assembled by links from the assorted subsystems, thus making it easy to make. Or even nmake.
>>It would be really nice to agree a path towards a brighter future where VMMaker doesn't have to copy files and worry about damned permissions/attributes/flavours/whatever. Thoughts please?
>
>
>Bury it I'd say. Who was using it anyway?
>
>Btw, I think it would be nice to revive
>
> http://www.squeaksource.com/VMMaker.html
>
>Also, some idea about how to handle plugins development-wise would be nice. The unix VM now ships several non-default plugins (DBus, GStreamer, Rome, maybe more) that one has to download from different repositories. Maybe the source for those should be added to the VMMaker repo? Or added to SVN? Maybe even a whole VMMaker image?
>
>- Bert -

I agree, it would be nice to have one place where the source for all the plugins lives. Failing that, at least a index there that shows where they all can be found.

And if working on all this VMMaker stuff, how about making the naming of the plugins consistent?

I have found at least:

internal plugin B3DEnginePlugin generated as Squeak3D
internal plugin BalloonEnginePlugin generated as B2DPlugin
internal plugin BitBltSimulation generated as BitBltPlugin
internal plugin DSAPlugin generated as DSAPrims
internal plugin DeflatePlugin generated as ZipPlugin
internal plugin FFIPlugin generated as SqueakFFIPrims
internal plugin KlattSynthesizerPlugin generated as Klatt
internal plugin LargeIntegersPlugin generated as LargeIntegers

Very confusing.

Ken G. Brown