Vm-dev May 2013

vm-dev@lists.squeakfoundation.org

20 participants
145 discussions

Fwd: squeak-vm 1:4.10.2.2614-1 MIGRATED to testing
by Bert Freudenberg 06 May '13

06 May '13

Begin forwarded message: > From: Debian testing watch <noreply(a)release.debian.org> > Subject: squeak-vm 1:4.10.2.2614-1 MIGRATED to testing > Date: 5. Mai 2013 18:40:02 MESZ > To: squeak-vm(a)packages.debian.org > > FYI: The status of the squeak-vm source package > in Debian's testing distribution has changed. > > Previous version: 1:4.4.7.2357-1.1 > Current version: 1:4.10.2.2614-1 > > -- > This email is automatically generated once a day. As the installation of > new packages into testing happens multiple times a day you will receive > later changes on the next day. > See http://release.debian.org/testing-watch/ for more information.

2 1

VM Maker: VMMaker.oscog-dtl.286.mcz
by commits＠source.squeak.org 04 May '13

04 May '13

David T. Lewis uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-dtl.286.mcz ==================== Summary ==================== Name: VMMaker.oscog-dtl.286 Author: dtl Time: 4 May 2013, 11:29:25.237 am UUID: 8be237d9-7812-4792-9723-90f9cff0c2e9 Ancestors: VMMaker.oscog-eem.285 Replace broken primitiveUtcWithOffset with a version that works. =============== Diff against VMMaker.oscog-eem.285 =============== Item was changed: ----- Method: InterpreterPrimitives>>primitiveUtcWithOffset (in category 'system control primitives') ----- primitiveUtcWithOffset "Answer an array with UTC microseconds since the Posix epoch and the current seconds offset from GMT in the local time zone. This is a named (not numbered) primitive in the null module (ie the VM)" + | epochDelta offset resultArray utcMicroseconds | - | offset resultArray | <export: true> + <var: #epochDelta declareC: 'static usqLong epochDelta= 2177452800000000ULL'> + <var: #utcMicroseconds type: #usqLong> + <var: #offset type: #sqLong> + utcMicroseconds := self ioUTCMicroseconds. + offset := self ioLocalMicroseconds - utcMicroseconds. + offset := offset / 1000000. + objectMemory pushRemappableOop: (objectMemory integerObjectOf: offset). + objectMemory pushRemappableOop: (self positive64BitIntegerFor: utcMicroseconds - epochDelta). - <var: #clock type: 'sqLong'> - offset := self ioUTCMicroseconds - self ioLocalMicroseconds. - objectMemory pushRemappableOop: (self positive64BitIntegerFor: self ioUTCMicroseconds). resultArray := objectMemory instantiateClass: objectMemory classArray indexableSize: 2. self stObject: resultArray at: 1 put: objectMemory popRemappableOop. + self stObject: resultArray at: 2 put: objectMemory popRemappableOop. - self stObject: resultArray at: 2 put: (objectMemory integerObjectOf: offset). self pop: 1 thenPush: resultArray !

1 0

Re: [Vm-dev] Unix socket plugin patch for systemd
by Max Leske 02 May '13

02 May '13

> On Thu, May 02, 2013 at 05:22:07PM +0200, Max Leske wrote: > > > > We've created a patch for the unix socket plugin that allows for socket activation via systemd. > > > > This is how it works: > > 1. tell systemd to link a socket to the vm (e.g. 8080) > > 2. send a request to the socket > > 3. systemd will launch the vm and hold the request until the image is connected to the port > > 4. (here's where the patch comes in) connect to the socket in the image (e.g. by starting WAKom - WAKom startOn: 8080) > > > > The patch is necessary because the primitive would fail when connecting to the socket (the plugin thinks that the socket is already in use). > > > > So here's my question: who is responsible for the plugin or would like to integrate the patch? > > Hi Max, > > You've come to the right place. I'm guessing that your patches involve both the Smalltalk > (slang) and the platform C code. Yes, correct. The (hacky) version right now adds a new type of socket for systemd (now new primitive, maybe you'll want to do that). Then on the image side there's a bit of logic to determine the kind of socket and a consistency check of the systemd environment variable. So all in all it's really quite simple. > If so, it may be easiest if you just post the patches to the list for starters, and then we can sort out what needs to be done by whom. I'll try to post the patches next week. > Please also let us know which code base you are working with (trunk interpreter VM, Cog, other?). We use the 4.0.3-2202 interpreter VM and patched the plugin there for now. We also took a look at the newest version from http://gitorious.org/cogvm/blessed/trees/master/platforms/unix/plugins/Sock… and found that there weren't many differences. So we thought to apply the patch to that file. I think it shouldn't be much work to backport the patch to the interpreter VM after that (?). Actually, now that I think about it, it would probably make more sense to patch the interpreter VM trunk. That makes it easier for us to test before we post it. Anyway, I'll get back to you. > > For more information on contributing to the Unix VM, see Ian's documentation here: > > http://squeakvm.org/unix/download.html#caveats > http://squeakvm.org/cgi-bin/viewvc.cgi/squeak/trunk/platforms/unix/doc/READ… > > There are currently several branches of VM development that will be impacted by > a change to SocketPlugin, so we'll make sure they all get updated appropriately. That would be awesome! > > Thanks! > > Dave

2 1

sqAtomicOps.h garbaged
by Nicolas Cellier 02 May '13

02 May '13

Hi Tim, It seems than line 224 of cross platform sqAtomicOps.h was garbaged by a /tmp/ccf1WMiY.s: in commit 2727

7 12

Unix socket plugin patch for systemd
by Max Leske 02 May '13

02 May '13

We've created a patch for the unix socket plugin that allows for socket activation via systemd. This is how it works: 1. tell systemd to link a socket to the vm (e.g. 8080) 2. send a request to the socket 3. systemd will launch the vm and hold the request until the image is connected to the port 4. (here's where the patch comes in) connect to the socket in the image (e.g. by starting WAKom - WAKom startOn: 8080) The patch is necessary because the primitive would fail when connecting to the socket (the plugin thinks that the socket is already in use). So here's my question: who is responsible for the plugin or would like to integrate the patch? Cheers, Max

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2013