Vm-dev March 2012

vm-dev@lists.squeakfoundation.org

23 participants
41 discussions

Start a nNew thread

Hello
by Chris Richardson 23 Mar '12

23 Mar '12

Hello Everybody!!

2 1

Re: [Pharo-project] Behavior modification VM crash
by Eliot Miranda 22 Mar '12

22 Mar '12

On Thu, Mar 22, 2012 at 3:32 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-03-22, at 17:26, Eliot Miranda wrote: > > > > > > > On Thu, Mar 22, 2012 at 7:26 AM, Camillo Bruni <camillobruni(a)gmail.com> > wrote: > > > > On 2012-03-22, at 15:06, Stefan Marr wrote: > > > > > > > > On 22 Mar 2012, at 14:45, Camillo Bruni wrote: > > > > > >> let's have some fun and do > > >> > > >> Object subclass: #Behavior > > >> uses: TPureBehavior > > >> instanceVariableNames: 'superclass methodDict format layout' > > >> classVariableNames: 'ObsoleteSubclasses' > > >> poolDictionaries: '' > > >> category: 'Kernel-Classes' > > >> > > >> proceed over the several warnings not to change Behavior and BOOM! :D > > > > > > Check classNameIndex and thisClassIndex in the VM implementation. > > > They are typically the hardcoded indices into the expected object > layout of Class objects. > > > > > > And you just changed the layout -> BOOM! magic ;) > > > > > > I don't know how much overhead it is to examine such kind of indices > dynamically, but we do deduce indices based on inst var names to be able to > support the different object layouts. > > > For my stuff, I do that at VM startup, which would not help you. > > > > They would be expensive to recompute all the time (they're used in debug > printing). But they're not expensive to compute. So they could be > recomputed easily. See below. > > > > > > > David did it dynamically for the Process class and checked the object > identity of the class I think, to know when to update the index table after > a layout change. > > > > right. I guess I will have to move it to some further position... > > although I have an old image with: > > > > Behavior subclass: #ClassDescription > > layout: PointerLayout > > uses: TClassAndTraitDescription > > slots: { > > #instanceVariables => Slot. > > #organization => Slot. > > #layout => Slot. > > } > > classSlots: {} > > globals: '' > > category: #'Kernel-Classes' > > > > > > which works under said Cog version :/. I guess I will just have to find > some older VM which will support the changes > > > > I think we should make the VM work for this. classNameIndex and > thisClassIndex should only be used for debug printing, at least thats my > intent, and it would be possible to flush them and recompute them as a > side-effect of e.g. a flushCache primitive. > > > > Camilo, would you create a reproducible case for me, an image that > applies this change at start-up? Thanks. > > > > Also, can we please get into the habit of cc'ing vm-dev for issues that > touch on the VM? I ask this so that subsequent searching for VM issues can > be confined to a search of vm-dev archives. Again AdvThanksance. > > Submitted a bug report here: > http://code.google.com/p/cog/issues/detail?id=76 > > the attached *.st files fail under Cog / StackVM. It would be indeed nice > if they would work. > Which maybe it will one day if you can put in the effort to describe how to reproduce the bug properly. There's no pointer to a suitable image. There are no instructions beyond "use these files". How about a link to an image, plus a small script that files in the files? Or even better how about constructing an image that does this at startup so that the VM maintainers only have to fire up the image instead of wasting time setting up files? > best > cami > > > > > > -- best, Eliot

1 0

Re: [Pharo-project] Behavior modification VM crash
by Eliot Miranda 22 Mar '12

22 Mar '12

On Thu, Mar 22, 2012 at 7:26 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > > On 2012-03-22, at 15:06, Stefan Marr wrote: > > > > > On 22 Mar 2012, at 14:45, Camillo Bruni wrote: > > > >> let's have some fun and do > >> > >> Object subclass: #Behavior > >> uses: TPureBehavior > >> instanceVariableNames: 'superclass methodDict format layout' > >> classVariableNames: 'ObsoleteSubclasses' > >> poolDictionaries: '' > >> category: 'Kernel-Classes' > >> > >> proceed over the several warnings not to change Behavior and BOOM! :D > > > > Check classNameIndex and thisClassIndex in the VM implementation. > > They are typically the hardcoded indices into the expected object layout > of Class objects. > > > > And you just changed the layout -> BOOM! magic ;) > > > > I don't know how much overhead it is to examine such kind of indices > dynamically, but we do deduce indices based on inst var names to be able to > support the different object layouts. > > For my stuff, I do that at VM startup, which would not help you. > They would be expensive to recompute all the time (they're used in debug printing). But they're not expensive to compute. So they could be recomputed easily. See below. > > David did it dynamically for the Process class and checked the object > identity of the class I think, to know when to update the index table after > a layout change. > > right. I guess I will have to move it to some further position... > although I have an old image with: > > Behavior subclass: #ClassDescription > layout: PointerLayout > uses: TClassAndTraitDescription > slots: { > #instanceVariables => Slot. > #organization => Slot. > #layout => Slot. > } > classSlots: {} > globals: '' > category: #'Kernel-Classes' > > > which works under said Cog version :/. I guess I will just have to find > some older VM which will support the changes > I think we should make the VM work for this. classNameIndex and thisClassIndex should only be used for debug printing, at least thats my intent, and it would be possible to flush them and recompute them as a side-effect of e.g. a flushCache primitive. Camilo, would you create a reproducible case for me, an image that applies this change at start-up? Thanks. Also, can we please get into the habit of cc'ing vm-dev for issues that touch on the VM? I ask this so that subsequent searching for VM issues can be confined to a search of vm-dev archives. Again AdvThanksance. -- best, Eliot

1 0

limiting compiler warnings...
by Camillo Bruni 21 Mar '12

21 Mar '12

I am quickly trying to limit the number of warnings we get when compiling cog. The current output is amazingly verbose, and utterly useless when looking for possible bugs :/. Furthermore it seems that cared about the following warning: /Users/cami-data/education/phd/project/cog/dh83s-blessed/src/vm/gcc3x-cointerp.c:2066: warning: passing argument 1 of ‘longAt’ makes integer from pointer without a cast what would be the easiest way to introduce an auto-cast for longAt and family? I think the easiest solution would be to reintroduce the macros that are currently disabled, no? best cami

7 11

Re: [Pharo-project] Make arduino work on linux with cog vm
by Igor Stasenko 20 Mar '12

20 Mar '12

On 20 March 2012 22:32, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Try VM from here: http://squeakvm.org/unix/ > ...but you cannot use the latest Pharo image from CI server (because > it is saved in CogVM). But you can try official 1.3. > I think a better alternative would be to fix VM and make it work. I assuming there's something wrong with SerialPlugin , which used by SerialPort, no? I can't remember if this plugin is included into VM by default or not.. > -- Pavel > > > On Tue, Mar 20, 2012 at 9:21 PM, Mariano Vicente <m.vicent(a)gmail.com> wrote: >> Thanks a lot. >> >> Could you send me a link with a old vm version? >> >> Sorry but I'm a newie with Pharo :P >> >> Cheers, >> Mariano >> >> >> >> On Tue, Mar 20, 2012 at 5:08 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >>> >>> Yes, that seems to be a CogVM problem. I tried it now and Cog cannot >>> open the port but an old Squeak4.1 of 17 April 2010 [latest update: >>> #9957] can. >>> >>> -- Pavel >>> >>> On Tue, Mar 20, 2012 at 8:30 PM, Mariano Vicente <m.vicent(a)gmail.com> >>> wrote: >>> > Hi Everybody. >>> > >>> > I'm just started with Pharo, and Arduino. And i like to comunicate both. >>> > I >>> > instaled the package sent by Ricardo Moran in a Pharo 1.4 with the Cogvm >>> > from the Jenkins server, but i can't make the serials port works. The >>> > Arduino board, i have, is connected to usb, wich ubuntu detects as >>> > /dev/ttyACM0. >>> > >>> > I tried opening serial ports, like this: >>> > >>> > sp:=SerialPort new. >>> > sp openPort: '/dev/ttyACM0'. >>> > >>> > sp openPort: 'ttyACM0'. >>> > >>> > sp openPort: 'ACM0'. >>> > >>> > sp openPort: '/ttyACM0'. >>> > >>> > But all they fail with a error saying ""Cannot open..." >>> > After that, i have also, tried this: >>> > >>> > (1 to: 10000) select:[:port | [SerialPort new openPort:port;close. true] >>> > on:Error do: [false]] >>> > >>> > and had a empty collection. >>> > >>> > And also tried giving full permissions to the port and executed the vm >>> > sudoed... >>> > >>> > Are serial ports working on ubuntu?. Do i have to download a special >>> > vm?. (I >>> > would like to do a demo of arduino on monday, at work, and i would like >>> > to >>> > do in Pharo.) >>> > >>> > Cheers, >>> > Mariano >>> >> > -- Best regards, Igor Stasenko.

1 0

Re: [Pharo-project] can't load VMMaker into 1.3 as suggested by collaboractive book
by Henrik Sperre Johansen 20 Mar '12

20 Mar '12

On 20.03.2012 08:55, Max Leske wrote: > I tried to load VMMaker into Pharo 1.3 (http://book.pharo-project.org/book/Virtual-Machine/Building/VMMakerTool). However, there's a dependency on Balloon3D-Plugins-bf.5 that contains underscore assignments which leads to syntax errors during load. Even the "fix" #pharoUndescoreAssignment run manually doesn't help. > > Maybe I'm doing this all wrong… All I want is to write a CRC plugin… > > Any suggestions? > > Cheers, > Max I went through a while back and removed all underscore assignments, but I don't have write access to the repository. You can find the .mcz / .cs at: http://dl.dropbox.com/u/6751081/BalloonPluginNoUnderscores.zip Cheers, Henry

2 1

Pharo Consortium Important Documents and Request for Feedback
by stephane ducasse 19 Mar '12

19 Mar '12

Dear Pharo Friends and Supporters We worked a lot with INRIA lawyers and tried a lot of different scenarios. We arrived to a setup that make sense now we would like to get your input. Please have a look at the following powerpoint presentation and feel free to comment! We provide some sketches for the consortium fees and benefits for you. But we need your input! If you are not in the mailing-list: send us a mail to board(a)pharo-project.org. Remember that what we want to achieve is to be able to pay one (or more) full time engineer to help us improving our system and making that our future is bright. Since it may be difficult to follow closely our vision, dreams and current development efforts you can read the pharo vision document. https://gforge.inria.fr/frs/download.php/30436/PHARO-ENG-V4.2.pdf https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf The Pharo Team Remember: The best way to predict the future is to invent it. A. Kay And we want to do it :)

1 0

Re: [squeak-dev] filesize reporting 0 for very large files
by David T. Lewis 19 Mar '12

19 Mar '12

On Sun, Mar 18, 2012 at 10:00:46PM -0400, David T. Lewis wrote: > On Sun, Mar 18, 2012 at 06:55:10PM -0700, Eliot Miranda wrote: > > Hi David, > > > > On Sun, Mar 18, 2012 at 6:30 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > > > On a Linux system, the data types that represent file positions are 32 bits > > > in size when the program is compiled in 32-bit mode (using the -m32 > > > compiler > > > option), and they are 64 bits in size when the program is compiled in > > > 64-bit > > > mode. The relevant data types are off_t and size_t, and if you compile the > > > following in 32-bit mode (-m32) and compare the same program compiled in > > > 64-bit mode, you can see the difference: > > > > > > #include <stdio.h> > > > #include <sys/types.h> > > > main() { > > > printf("off_t is %d\n", sizeof(off_t)); > > > printf("size_t is %d\n", sizeof(size_t)); > > > } > > > > > > > Not quite. One can modify this by defining something like > > _LARGEFILE64_SOURCE at compile time. e.g. > > see _LARGEFILE_SOURCE _LARGEFILE64_SOURCE & _FILE_OFFSET_BITS in > > http://www.delorie.com/gnu/docs/glibc/libc_13.html. I'll check that the > > appropriate one is defined when building Cog asap. > > Excellent, thank you! (CC to vm-dev) I note that Nicolai Hess has just added a note to the Mantis issue with a similar tip and pointers to additional things that may need attention in the support code. http://bugs.squeak.org/view.php?id=7522 Dave

2 1

Fwd: filesize reporting 0 for very large files
by Bert Freudenberg 18 Mar '12

18 Mar '12

Begin forwarded message: > From: Nicolai Hess <nicolaihess(a)googlemail.com> > Subject: Re: [squeak-dev] filesize reporting 0 for very large files > Date: 18. März 2012 21:31:05 MEZ > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > For the 32Bit unix VM, > primitiveDirectoryLookup and primitiveFileSize doesn't work with files larger than > 2^32 bits. > Possible workaround/fix. > Build with -D_FILE_OFFSET_BITS=64 > and replace ftell,fseek in sqFilePluginBasicPrims with ftello,fseeko. > Now reading filesize for files larger than 2^32 bits works, but I don't know if > there are any side effects. > > regards > Nicolai > >

1 0

cmake stopped working with Xcode 4.3
by Esteban Lorenzano 18 Mar '12

18 Mar '12

Hi, I just want to inform that I updated xcode (because I updated iOS) and CMake stopped to work. So, I'm taking some time to make it work again :( best, Esteban ps: that means an update will be necessary on jenkins after I make the changes :(

4 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev March 2012