Vm-dev October 2016

vm-dev@lists.squeakfoundation.org

30 participants
82 discussions

simplifying build system
by Gerardo Santana Gómez Garrido 20 Oct '16

20 Oct '16

I want to refer to https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/75 The idea is to reduce duplication to the minimum. There's no need to have so much code duplicated. The changes introduced in pull request #75 factorizes code and still creates a different directory to output intermediate products, as I think was the intention of having so many subdirectories and copies of the mvm script. Consider this change as a first shy step towards having a single source tree and Makefile to build any platform. -- Gerardo Santana

3 6

buildspurtrunkvmmakerimage.sh gives 404 error when run
by monty 20 Oct '16

20 Oct '16

Is this still the preferred way of getting a Spur VMMaker image?

1 0

Re: updating configure.ac
by Eliot Miranda 19 Oct '16

19 Oct '16

Hi Gerardo, On Tue, Oct 4, 2016 at 12:32 AM, Gerardo Santana Gómez Garrido < gerardo.santana(a)gmail.com> wrote: > Yes, energy and will. > > Actually I would like to keep autoconf. I found out some duplicated code > in the build.* directories that could probably be solved by using the > autotools properly. > > Are you strongly opposed to using autotools? May I try to make it work? > No, I'm not. I'm opposed to running it on each build. The scheme we've agreed upon is as follows (and I'm cc'ing vm-dev to include others working on this): 1. The correct realm for autoconf is in determining what facilities the platform provides, /not/ for deciding how to configure the VM, /not/ for generating Makefiles, etc. So autoconf (or CMake) should be run once per platform (updating after significant third-party software is installed, C compiler is updated, etc), and produces a config.h in the relevant build directory, e.g. build.linux32x86/config.h. 2. the VM is to be configured from config.h (which informs us as to what third-party libraries, os facilities, word sizes, etc are available for the current platform), the Makefile (e.g. build.macos32x86/pharo.cog.spur/Makefile), and plugins.int and plugins.ext (to determine the set of plugins to attempt to build; their makefiles may further filter-out plugins depending on available third-party libraries). So the build scheme we're trying to move towards is a) either autoconf or CMake is used to generate a config.h file in each build directory that defines platform facilities (#define HAS_EPOLL 1 et al). This is run occasionally, /not/ on every build b) use conventional Gnu Make makefiles, avoiding all the mkmf scripts in platforms/unix/conf, to build specific VMs Does that make sense? For me this is very important. See http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-February/ 119002.html and this is from a Squeak Oversight Board discussion before we moved to githug: "It was decided to leave the build system as-is using GNU Makefiles where available with a commitment to move to GNU Makefiles on Linux. We will use CMake to produce per-platform config files that identify platform facilities (such as epoll(2) vs kqueue(2) vs poll(s) vs select(3))." > On Mon, Oct 3, 2016 at 8:26 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Gerardo, >> >> welcome! >> >> On Sun, Oct 2, 2016 at 8:45 AM, Gerardo Santana Gómez Garrido < >> gerardo.santana(a)gmail.com> wrote: >> >>> Hi Eliot, >>> >>> what is the proper way to ask questions regarding building Clog? >>> >>> I just found that in opensmalltalk-vm/platforms/unix/config, configure >>> is not in sync with configure.ac >>> >> >> It may or may not be. Currently I can only reliably run make to generate >> a new configure script on CentOS 5.3. If I try on e.g. 6.x I get an >> invalid configure. We hope to eliminate configure soon and use a makefile >> style similar to the Mac and Windows platforms. Do you have energy to >> contribute to this? >> >> >>> >>> Thanks in advance. >>> >>> P. S. I have made squeak.clog.spur compile on OpenBSD, but I'm looking >>> for a better way to do it. >>> >>> -- >>> Gerardo Santana >>> >> >> >> _,,,^..^,,,_ >> best, Eliot >> > > > > -- > Gerardo Santana > -- _,,,^..^,,,_ best, Eliot

9 39

Re: [Vm-dev] updating configure.ac
by Ben Coman 19 Oct '16

19 Oct '16

On Wed, Oct 19, 2016 at 6:14 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > Does the simulator works in Pharo? Along with Display working? > Clement seems to be working with a Squeak based one. It does not. But once I get through a few other things this is something I'd like to rectify. cheers -ben

2 1

Strange unix (Pi) vm event bug for july 2016 era vm build
by tim Rowledge 19 Oct '16

19 Oct '16

I have a really annoying bug afflicting a few users. As in several million… The latest release of Raspbian includes a cog vm tagged 5.0-201607181657 and suffers from a very annoying habit of not (seemingly) passing in key-up events if another key has gone down since the first did. In ordinary typing of course this isn’t often an issue but for Scratch scripts that test things like cursor key presses (say for example, AsteroidBlaster) it gets very annoying because you get completely screwed by what seems to be a jammed key. Aside for explanatory purpose - Scratch wants to be able to query whether a certain key is up or down, rather than making use of events per se. To provide this I have a very simple and so far effective keyboard event listener class that merely keeps a big array of true/false for each ascii value. Scratch checks that table for the requested ascii value. On previous release vms and indeed a september 28 build, there was/is no problem. The key events come in, the listener gets pinged, the state is updated. Asteroids are blasted. With the july vm (the one shipped to several million kids) the up events are not coming in in quite the same way; if I press left-cursor, then right cursor, then release right and finally left, that last left-cursor-up event seems not to arrive. The *same* image on the other vm(s) works. So far I’m completely unable to find any difference in the code! I’ve checked sqUnixEvent.c & sqUnixX11.c for example - any other plausible places where key events might get mangled? I see some recent-ish changes for some squeak/pharo labelling differences but that’s it. Can anyone recall making changes around the june/july era that might have had some effect? Not to mention something that *fixed* the problem sometime in early September? Obviously one could say it’s fixed and to hell with it but it would be nice to understand what on earth went wrong. I also have to work out how it didn’t get spotted during the release testing but that;s a different problem. tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DMZ: Divide Memory by Zero

8 23

[OpenSmalltalk/opensmalltalk-vm] 86a3d4: CogVM source as per VMConstruction-Plugins-OSProce...
by GitHub 19 Oct '16

19 Oct '16

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: 86a3d484ac2aa9dc1087ccac999b3f1cd953ba42 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/86a3d484ac2aa9dc10… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2016-10-18 (Tue, 18 Oct 2016) Changed paths: M scripts/gitci M src/plugins/UnixOSProcessPlugin/UnixOSProcessPlugin.c M src/plugins/VMProfileLinuxSupportPlugin/VMProfileLinuxSupportPlugin.c Log Message: ----------- CogVM source as per VMConstruction-Plugins-OSProcessPlugin.oscog-eem.54 & VMMaker.oscog-eem.1961. Implement Gerardo Santana's fix to the OSProcessPlugin and VMProfiler for OpenBSD in the right place. Regenerate the two plgins. Fix a slip in the gitci script which didn't list unofficial files.

1 0

VM Maker: VMMaker.oscog-eem.1961.mcz
by commits＠source.squeak.org 19 Oct '16

19 Oct '16

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1961.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1961 Author: eem Time: 18 October 2016, 3:34:37.516235 pm UUID: e0793c3c-8f65-4263-9c21-811c44976606 Ancestors: VMMaker.oscog-eem.1960 Implement Gerardo Santana's fix to the linux VMProfiler for OpenBSD in the right place. =============== Diff against VMMaker.oscog-eem.1960 =============== Item was changed: ----- Method: VMProfileLinuxSupportPlugin class>>declareHeaderFilesIn: (in category 'translation') ----- declareHeaderFilesIn: cg cg addHeaderFile: '<limits.h>'; + addHeaderFile: '#ifdef __OpenBSD__\#include <dlfcn.h>\#endif' withCRs; + addHeaderFile: '#ifndef _GNU_SOURCE\# define _GNU_SOURCE\#endif\#include <link.h>' withCRs; + addHeaderFile: '#ifndef RTLD_NODELETE\# define RTLD_NODELETE 0\#endif' withCRs! - addHeaderFile: '#ifndef _GNU_SOURCE\# define _GNU_SOURCE\#endif\#include <link.h>' withCRs!

1 0

Accessing effectiveProcess from a primitive
by Ben Coman 17 Oct '16

17 Oct '16

After falling down a rabbit hole chasing some ideas for waitAcquire for the OwnedLock primitives (where I learnt a lot) which came to a dead end, and then a few other distractions I'm returnign to complete this. I have a query regarding simulation of the primitives via... Context>>doPrimitive:method:receiver:args: The activeProcess is important to the OwnedLock primitives since they record which process acquired the lock, however IIUC the active process is confused when debugging for which effectiveProcess is provided to clarify things. So in #doPrimitive:method:receiver:args: I am passing the effectiveProcess via the stack and the primitive does... argumentCount > 0 ifTrue: [ownedLock := self stackValue: 1. "rcvr" activeProc := self stackTop] ifFalse: [ownedLock := self stackTop. "rcvr" activeProc := self activeProcess]. However I am thinking it would be better from the primitive to directly access the effectiveProcess instance variable of Process. However Squeak 5.1 has ivars... Link subclass: #Process instanceVariableNames: 'suspendedContext priority myList threadId effectiveProcess name island env' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Processes' while Pharo 60257 has ivars... Link subclass: #Process instanceVariableNames: 'suspendedContext priority myList name env effectiveProcess terminating' classVariableNames: 'InheritablePSKeys PSKeys PSKeysSema' package: 'Kernel-Processes' where the threadId variable "is used by multi-threaded CogVMs to control process-to-thread binding. It's required to be the fourth instance variable." So first a side question... Should Pharo add threadId? And my main question, can I lock effectiveProcess in as the fifth instance variable so OwnedLock primitive can access it from the VM ? cheers -ben

2 1

Re: [Pharo-dev] [squeak-dev] Re: large images
by David T. Lewis 15 Oct '16

15 Oct '16

Ah, right - sorry for my misunderstanding. Certainly it would make sense to eliminate the GC if we are going to quit the image anyway. Processing the shutdown list and finalization queue probably makes sense as a matter of policy, even if in practice these actions are rarely needed. For cases in which, for example, database sessions are active, it might be very important to ensure clean shutdown when quitting the image. Dave On Fri, Oct 14, 2016 at 11:08:56PM -0500, John Brant wrote: > The time I was talking about was the time to quit the image without > saving. This time seems to be dependent on the size of the image. For > example, a 100MB image quits almost immediately, but a couple GB one > takes 5 or so seconds and my 7GB one was taking ~15 seconds. > > > John Brant > > > On 10/14/2016 05:34 PM, David T. Lewis wrote: > >Hi, > > > >Let's measure where the time is going before we fix it. I have saved V3 > >images > >of that size and more, and it takes a very long time to write the image > >file > >independent of any GC or finalization actions that need to happen. We > >should > >measure this on a large Spur image save, but I suspect that the dominant > >factor > >will turn out to be the time that it takes to flush all those gigabytes out > >to storage. Garbage collection and finalization actions might be just > >round-off > >error. > > > >Dave > > > > > >On Fri, Oct 14, 2016 at 08:29:13AM -0700, Eliot Miranda wrote: > >>Hi Both, > >> > >> let me try again :-/ > >> > >>>On Oct 8, 2016, at 10:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>> > >>>Nice! > >>> > >>>I put Eliot in CC :). > >>> > >>>@Eliot: John was playing with some large images and I asked him if he > >>>could save/load to see what happens. The report is below. Nice job :). > >>> > >>>Doru > >>> > >>> > >>>>On Oct 8, 2016, at 7:48 PM, John Brant <brant(a)refactoryworkers.com> > >>>>wrote: > >>>> > >>>>I loaded my model (6.8GiB on linux), saved the image (7.2GB), and > >>>>started the image. It all worked. It took a few minutes to load the > >>>>image, but it worked. It takes ~15 seconds to quit an image that large. > >>>>I'm not sure what quit is doing, but it appears to be dependent on the > >>>>image size. > >> > >>Regrettably the squeak vm does a full gc on snapshot, and then, > >>unavoidably, it does a scan of all contexts in the heap, changing any > >>with machine code pcs to have bytecode pcs so that the image can be > >>restarted on a different version/platform. It then writes the heap > >>segments to the file. > >> > >>I guess the scan could be folded into the gc. This is a long time to > >>wait! > >> > >>The gc makes sense only as a way of voiding new space; image loading is > >>simplified only having to load old space segments. It does /not/ make > >>sense semantically because and finalization actions it triggers cannot be > >>responded to until after the snapshot. > >> > >>Instead, it makes much more sense for the image to invoke a full gc > >>immediately prior to snapshot, and drain the finalization queue > >>(something I guess will happen implicitly due to finalization process > >>priority). This means that expected finalization activities such as > >>flushing and closing output files will actually take place. The existing > >>architecture effectively throws these actions away. > >> > >>Both squeak and pharo communities could do well to discuss this and agree > >>on an approach. > >> > >> > >>>> > >>>> > >>>>John Brant > >>> > >>>-- > >>>www.tudorgirba.com > >>>www.feenk.com > >>> > >>>"Every thing has its own flow." > >>> > >>> > >>> > >>> > >>> > >

1 0

Re: large images
by Eliot Miranda 15 Oct '16

15 Oct '16

Hi Both, let me try again :-/ > On Oct 8, 2016, at 10:49 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Nice! > > I put Eliot in CC :). > > @Eliot: John was playing with some large images and I asked him if he could save/load to see what happens. The report is below. Nice job :). > > Doru > > >> On Oct 8, 2016, at 7:48 PM, John Brant <brant(a)refactoryworkers.com> wrote: >> >> I loaded my model (6.8GiB on linux), saved the image (7.2GB), and started the image. It all worked. It took a few minutes to load the image, but it worked. It takes ~15 seconds to quit an image that large. I'm not sure what quit is doing, but it appears to be dependent on the image size. Regrettably the squeak vm does a full gc on snapshot, and then, unavoidably, it does a scan of all contexts in the heap, changing any with machine code pcs to have bytecode pcs so that the image can be restarted on a different version/platform. It then writes the heap segments to the file. I guess the scan could be folded into the gc. This is a long time to wait! The gc makes sense only as a way of voiding new space; image loading is simplified only having to load old space segments. It does /not/ make sense semantically because and finalization actions it triggers cannot be responded to until after the snapshot. Instead, it makes much more sense for the image to invoke a full gc immediately prior to snapshot, and drain the finalization queue (something I guess will happen implicitly due to finalization process priority). This means that expected finalization activities such as flushing and closing output files will actually take place. The existing architecture effectively throws these actions away. Both squeak and pharo communities could do well to discuss this and agree on an approach. >> >> >> John Brant > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing has its own flow." > > > > >

3 2

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev October 2016