Vm-dev February 2019

vm-dev@lists.squeakfoundation.org

33 participants
94 discussions

Re: [Vm-dev] [squeak-dev] [Pharo-dev] Squeak and Tonel
by Eliot Miranda 18 Feb '19

18 Feb '19

Stephane, On Sun, Feb 17, 2019 at 1:33 PM Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Eliot > > Contrary to you I do not wish your death. > "Drop dead" does not mean I want you dead. It is English for "Dégagé". > So can you respect me? > No. I do not. I've got to the end of my attempt to deal with your destructive relationships. I am merely one in a long line including Camillo, Cl ément, and others. One reason I can't respe3ct you is that you are not a man of your word. You sent an email 23 minutes ago that proudly declared "This is my last email sent to you.". Well done for keeping your word for 23 minutes. What's your record? > > Stef > > On 17 Feb 2019, at 22:30, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Sun, Feb 17, 2019 at 1:00 PM ducasse <stepharo(a)netcourrier.com> wrote: > >> Hi eliot >> >> What is common in your thread is that we always look like the super >> emotional, or bad guys. >> You never ask yourselves why Esteban left the VM mailing-list. >> > > What is common is that I discuss technical matters (difficulties in using > Tonel/git, architectural issues with developing the VM) and organizational > issues (Estebans' unhelpful response regarding an option in Tonel) and you > immediately personalize, do not bring up a single technical issue, and then > make grand pronouncements like :this is the last email I'll send you". > Laughable and sad. > > >> >> And I do not see why you cannot fork Tonel to produce your own version. >> Git is about distributed projects. People do that all the time. You can >> take Tonel and hack it to death >> without having your hacks pushed back into Pharo and this is perfectly ok >> for us. >> So Esteban has the right to say no and you have the right to hack your >> own version. >> >> If you want to have some support for porting Scorch/Sista to github and >> loading you should ask >> but asking it more nicely. >> >> About the simulation of the UI, if you do not talk to us we cannot pay >> attention. >> I do not see why we cannot keep a package with the image level UI for the >> simulator. >> Now again you are talking about collaboration but you do not talk to us >> and you do not >> listen to us so do not expect that people are willing to spend their free >> time to help. >> >> >> I had deep concerns that the pursuit of git integration would end up >> splitting the Pharo and Squeak communities and indeed this is now in >> progress. I am utterly unmotivated by the lack of cooperation, the sheer >> arrogance and bullying of those that say "you will move to git/tonel or >> else”, >> >> >> This is fun to ask Pharo not to grow up to use modern technology to >> manage source code under the >> premisses that Squeak cannot or will not. >> This is so funny how you state it. I will not comment more than that. >> People around are adults and they will be able to judge by themselves. >> >> and considering leaving VMMaker altogether. >> >> >> If you leave VMMaker, let us know because we will port it to Github and >> make it work in Pharo. >> Esteban did it several times in the past. At least this will have the >> benefit to clarify the situation. >> >> I think that this is good that you tell us that you do not want to >> cooperate with us. >> This will have at least the impact to kick our ass and pay attention to >> us. >> >> The only things that are keeping me interested are Ron Teitelbaum's Terf >> and me pursuing a PhD on register allocation in the context of Sista/Scorch >> with Robert Hirshfeld's group at HPI. >> >> Here's the kind of crap people like Ducasse throw at me: >> >> "Eliot >> >> At the end of the day I will probably ask the two phds that should work >> on language design to use truffle or pypy >> because let us face it we cannot work with the Pharo VM. Else we will >> simply have to fork it (because we do not want to have >> to jump over cuis, newspeak, squeak code constraints and I do not what) >> and it will be another drama is in the pico world >> of the “open” smalltalk VM. " >> >> I am so over this crap. >> >> >> This is not a crap. I can restate what I said. Because of responsibility >> of a research team and creating a future for students. You know I’m not >> alone, I have quite some responsibility towards PhD students >> of my group and yes I cannot make them fail by construction (or produce >> unadequate results) >> just by imposing them to use a system with far too many constraints. >> >> I will not ask them to work on the openSmalltalk vm directly because this >> is not their responsibilities >> to have to jump over newspeak ifdef and others. A job of a PhD is to be >> able to brainstorm and create new ideas. Look at Stefan Marr (He is working >> on SOM or Truffle). >> >> Now you can think that I’m an asshole, arrogant, or I do not know pick >> what you want. >> ***I do not care***. I do not have Diva syndrome I have responsibilities >> towards people. >> >> I was discussing with some truffle experts and they told me that this is >> can be complex. I believe it. >> I would like to avoid pypy for obvious reasons. So what we will probably >> do for their PhD is to see if we can use a light version of opensmalltalk. >> I do not want to ask them to jump over many things that are totally useless >> for them all the time. >> >> >> PS: personnally I do not get why VMMaker would be the only project on >> earth that cannot be managed using git and Pharo. >> But for us the future is Git and we will continue to build on this >> infrastructure. >> >> >> Stef >> >> >> _,,,^..^,,,_ >> best, Eliot >> >> >> > > -- > _,,,^..^,,,_ > best, Eliot > > > -------------------------------------------- > Stéphane Ducasse > http://stephane.ducasse.free.fr > http://www.synectique.eu / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > FAX 03 59 57 78 50 > TEL 03 59 35 86 16 > S. Ducasse - Inria > 40, avenue Halley, > Parc Scientifique de la Haute Borne, Bât.A, Park Plaza > Villeneuve d'Ascq 59650 > France > > > -- _,,,^..^,,,_ best, Eliot

2 1

FFI Testing - Curiouser and curiouser!
by ken.dickey＠whidbey.com 18 Feb '19

18 Feb '19

I noted a number of code generation differences between various gcc versions for aarch64, but there is something different going on. When I copied VM binaries produced on the Chromebook Plus to Raspberry Pi 3 (ArchLinuxArm), the same 2 unit tests fail in Cuis! So I am now guessing there must be a shared library difference (perhaps libm ?) Having the same 2 tests fail on x86_64 would preclude a bad CPU chip. ??? -KenD

4 6

Re: [Vm-dev] [Pharo-dev] [squeak-dev] Squeak and Tonel
by Eliot Miranda 17 Feb '19

17 Feb '19

On Sun, Feb 17, 2019 at 1:00 PM ducasse <stepharo(a)netcourrier.com> wrote: > Hi eliot > > What is common in your thread is that we always look like the super > emotional, or bad guys. > You never ask yourselves why Esteban left the VM mailing-list. > What is common is that I discuss technical matters (difficulties in using Tonel/git, architectural issues with developing the VM) and organizational issues (Estebans' unhelpful response regarding an option in Tonel) and you immediately personalize, do not bring up a single technical issue, and then make grand pronouncements like :this is the last email I'll send you". Laughable and sad. > > And I do not see why you cannot fork Tonel to produce your own version. > Git is about distributed projects. People do that all the time. You can > take Tonel and hack it to death > without having your hacks pushed back into Pharo and this is perfectly ok > for us. > So Esteban has the right to say no and you have the right to hack your own > version. > > If you want to have some support for porting Scorch/Sista to github and > loading you should ask > but asking it more nicely. > > About the simulation of the UI, if you do not talk to us we cannot pay > attention. > I do not see why we cannot keep a package with the image level UI for the > simulator. > Now again you are talking about collaboration but you do not talk to us > and you do not > listen to us so do not expect that people are willing to spend their free > time to help. > > > I had deep concerns that the pursuit of git integration would end up > splitting the Pharo and Squeak communities and indeed this is now in > progress. I am utterly unmotivated by the lack of cooperation, the sheer > arrogance and bullying of those that say "you will move to git/tonel or > else”, > > > This is fun to ask Pharo not to grow up to use modern technology to manage > source code under the > premisses that Squeak cannot or will not. > This is so funny how you state it. I will not comment more than that. > People around are adults and they will be able to judge by themselves. > > and considering leaving VMMaker altogether. > > > If you leave VMMaker, let us know because we will port it to Github and > make it work in Pharo. > Esteban did it several times in the past. At least this will have the > benefit to clarify the situation. > > I think that this is good that you tell us that you do not want to > cooperate with us. > This will have at least the impact to kick our ass and pay attention to > us. > > The only things that are keeping me interested are Ron Teitelbaum's Terf > and me pursuing a PhD on register allocation in the context of Sista/Scorch > with Robert Hirshfeld's group at HPI. > > Here's the kind of crap people like Ducasse throw at me: > > "Eliot > > At the end of the day I will probably ask the two phds that should work on language > design to use truffle or pypy > because let us face it we cannot work with the Pharo VM. Else we will > simply have to fork it (because we do not want to have > to jump over cuis, newspeak, squeak code constraints and I do not what) > and it will be another drama is in the pico world > of the “open” smalltalk VM. " > > I am so over this crap. > > > This is not a crap. I can restate what I said. Because of responsibility > of a research team and creating a future for students. You know I’m not > alone, I have quite some responsibility towards PhD students > of my group and yes I cannot make them fail by construction (or produce > unadequate results) > just by imposing them to use a system with far too many constraints. > > I will not ask them to work on the openSmalltalk vm directly because this > is not their responsibilities > to have to jump over newspeak ifdef and others. A job of a PhD is to be > able to brainstorm and create new ideas. Look at Stefan Marr (He is working > on SOM or Truffle). > > Now you can think that I’m an asshole, arrogant, or I do not know pick > what you want. > ***I do not care***. I do not have Diva syndrome I have responsibilities > towards people. > > I was discussing with some truffle experts and they told me that this is > can be complex. I believe it. > I would like to avoid pypy for obvious reasons. So what we will probably > do for their PhD is to see if we can use a light version of opensmalltalk. > I do not want to ask them to jump over many things that are totally useless > for them all the time. > > > PS: personnally I do not get why VMMaker would be the only project on > earth that cannot be managed using git and Pharo. > But for us the future is Git and we will continue to build on this > infrastructure. > > > Stef > > > _,,,^..^,,,_ > best, Eliot > > > -- _,,,^..^,,,_ best, Eliot

1 0

Re: [Vm-dev] [Pharo-dev] [squeak-dev] Squeak and Tonel
by Eliot Miranda 17 Feb '19

17 Feb '19

On Sun, Feb 17, 2019 at 1:22 PM ducasse <stepharo(a)netcourrier.com> wrote: > BTW Eliot, I just discovered by accident emails you sent me last week > there are full on insults . I will not forward them in this mailing-list > because it does not help. > This is not the first that you do that to me. The first time I went over > them and supported > Clément to work with you. Now I will not consider your mails anymore. > > Sorry but you cannot talk publicly about collaboration and privately > insult people that way. > > Now if you believe that I do pharo about ego then you do not understand > anything :) > And I will not try to convince you otherwise. This is my last email sent > to you. > Thank god for that. > > Stef > > On 17 Feb 2019, at 21:59, ducasse <stepharo(a)netcourrier.com> wrote: > > Hi eliot > > What is common in your thread is that we always look like the super > emotional, or bad guys. > You never ask yourselves why Esteban left the VM mailing-list. > > And I do not see why you cannot fork Tonel to produce your own version. > Git is about distributed projects. People do that all the time. You can > take Tonel and hack it to death > without having your hacks pushed back into Pharo and this is perfectly ok > for us. > So Esteban has the right to say no and you have the right to hack your own > version. > > If you want to have some support for porting Scorch/Sista to github and > loading you should ask > but asking it more nicely. > > About the simulation of the UI, if you do not talk to us we cannot pay > attention. > I do not see why we cannot keep a package with the image level UI for the > simulator. > Now again you are talking about collaboration but you do not talk to us > and you do not > listen to us so do not expect that people are willing to spend their free > time to help. > > > I had deep concerns that the pursuit of git integration would end up > splitting the Pharo and Squeak communities and indeed this is now in > progress. I am utterly unmotivated by the lack of cooperation, the sheer > arrogance and bullying of those that say "you will move to git/tonel or > else”, > > > This is fun to ask Pharo not to grow up to use modern technology to manage > source code under the > premisses that Squeak cannot or will not. > This is so funny how you state it. I will not comment more than that. > People around are adults and they will be able to judge by themselves. > > and considering leaving VMMaker altogether. > > > If you leave VMMaker, let us know because we will port it to Github and > make it work in Pharo. > Esteban did it several times in the past. At least this will have the > benefit to clarify the situation. > > I think that this is good that you tell us that you do not want to > cooperate with us. > This will have at least the impact to kick our ass and pay attention to > us. > > The only things that are keeping me interested are Ron Teitelbaum's Terf > and me pursuing a PhD on register allocation in the context of Sista/Scorch > with Robert Hirshfeld's group at HPI. > > Here's the kind of crap people like Ducasse throw at me: > > "Eliot > > At the end of the day I will probably ask the two phds that should work on language > design to use truffle or pypy > because let us face it we cannot work with the Pharo VM. Else we will > simply have to fork it (because we do not want to have > to jump over cuis, newspeak, squeak code constraints and I do not what) > and it will be another drama is in the pico world > of the “open” smalltalk VM. " > > I am so over this crap. > > > This is not a crap. I can restate what I said. Because of responsibility > of a research team and creating a future for students. You know I’m not > alone, I have quite some responsibility towards PhD students > of my group and yes I cannot make them fail by construction (or produce > unadequate results) > just by imposing them to use a system with far too many constraints. > > I will not ask them to work on the openSmalltalk vm directly because this > is not their responsibilities > to have to jump over newspeak ifdef and others. A job of a PhD is to be > able to brainstorm and create new ideas. Look at Stefan Marr (He is working > on SOM or Truffle). > > Now you can think that I’m an asshole, arrogant, or I do not know pick > what you want. > ***I do not care***. I do not have Diva syndrome I have responsibilities > towards people. > > I was discussing with some truffle experts and they told me that this is > can be complex. I believe it. > I would like to avoid pypy for obvious reasons. So what we will probably > do for their PhD is to see if we can use a light version of opensmalltalk. > I do not want to ask them to jump over many things that are totally useless > for them all the time. > > > PS: personnally I do not get why VMMaker would be the only project on > earth that cannot be managed using git and Pharo. > But for us the future is Git and we will continue to build on this > infrastructure. > > > Stef > > > _,,,^..^,,,_ > best, Eliot > > > -- _,,,^..^,,,_ best, Eliot

1 0

Call for Participation: <Programming> 2019
by Fabio Niephaus 15 Feb '19

15 Feb '19

<Programming> 2019 : The Art, Science, and Engineering of Programming April 1-4, 2019, Genova, Italy http://2019.programming-conference.org The International Conference on the Art, Science, and Engineering of Programming is a new conference focused on programming topics including the experience of programming. We have named it <Programming> for short. The conference is co located with the 12th European Lisp Symposium, several workshops, a poster and a demo session and the student research competition. Registration: February 25, 2019 (Early Registration Deadline) Register: https://2019.programming-conference.org/attending/Registration Venue: Hotel Bristol Palace, Genova https://2018.splashcon.org/venue/splash-2018-venue Keynotes: Heather Miller (Carnegie Mellon University) Lars Bak (Toitware Aps) Workshops PX/19 ProWeb’19 MiniPLOP ICW: Interconnecting Code Workshop MoreVMs’19 Salon des Refusés CoCoDo VPT Co-located Symposia 12th European Lisp Symposium (ELS) Invited Talks MoreVMs’19: Guilherme Ottoni (Facebook) ELS: Matthew Flatt (University of Utah) ELS: Stefan Monnier (Université de Montréal) ELS: Christophe Rhodes (Goldsmiths, University of London) ******************************************************** ORGANIZATION ******************************************************** General Chair: Davide Ancona, University of Genova Local Organizing Chair: Elena Zucca, University of Genova Program Chair: Matthew Flatt, University of Utah Organizing Committee: Walter Cazzola (Workshops Co-Chair), Università degli Studi di Milano Luca Franceschini (Student Volunteer Co-Chair), DIBRIS, University of Genova, Italy Philipp Haller (Student Research Competition Co-chair), KTH Royal Institute of Technology, Sweden Maurizio Leotta (Poster Co-Chair), DIBRIS, University of Genova, Italy Stefan Marr (Workshops Co-Chair), University of Kent Toni Mattis (Student Volunteer Co-Chair), Hasso Plattner Institute, University of Potsdam, Germany Ana Milanova (Student Research Competition Co-Chair), Rensselaer Polytechnic Institute Fabio Niephaus (Publicity Co-Chair), Hasso Plattner Institute, University of Potsdam Tobias Pape (Web Technology Chair), Hasso Plattner Institute, University of Potsdam Manuel Rigger (Demo Chair), Johannes Kepler University Linz, Austria Coen De Roover (Poster Co-Chair), Vrije Universiteit Brussel, Belgium Guido Salvaneschi (Publicity Co-Chair), TU Darmstadt, Germany Program Committee: Anya Helene Bagge, University of Bergen Mehdi Bagherzadeh, Oakland University Walter Cazzola, Università degli Studi di Milano Ravi Chugh, University of Chicago Joeri De Koster, Vrije Universiteit Brussel Christos Dimoulas, Northwestern University Susan Eisenbach, Imperial College London Richard P. Gabriel, Dream Songs, Inc. & HPI Jeremy Gibbons, University of Oxford Michael Greenberg, Pomona College Philipp Haller, KTH Royal Institute of Technology Robert Hirschfeld, HPI, University of Potsdam Eunsuk Kang, Carnegie Mellon University Stephen Kell, University of Cambridge Stefan Marr, University of Kent Tamara Rezk, Inria Joshua Sunshine, Carnegie Mellon University Steffen Zschaler, King's College London ******************************************************** <Programming> 2019 is kindly supported by AOSA ******************************************************** For more information, visit http://2019.programming-conference.org

2 1

FFI: Sometimes the magic works, sometimes it doesn't
by ken.dickey＠whidbey.com 14 Feb '19

14 Feb '19

Today it seems to be working (on RasPi3). source.squeak.org/inbox FFI-Tests-KenD.12 tests green. Squeak5.2-18231-64bit.image (18229 updated) source.squeak.org/FFI FFI-Pools-TorstenBergmann.4 FFI-Kernel-eem.56 FFI-Unix-mtf.4 FYI, -KenD

1 0

FFI Testing: more wierdness
by ken.dickey＠whidbey.com 14 Feb '19

14 Feb '19

When I run test code in a Workspace, the right answers happen. But in the test runner, the asserts fail. Now I am really confused. -KenD

1 0

Re: [Vm-dev] FFI Testing -- Moby Confused..
by ken.dickey＠whidbey.com 13 Feb '19

13 Feb '19

Plugged LePotato in place of RasPi. Possibly of interest: both success machines had gcc 6.3.0 failures had gcc 7.3.0 and 8.2.1 Perhaps a code generation change? -KenD

3 2

FFI Testing: Moby Confused; Halp!
by ken.dickey＠whidbey.com 12 Feb '19

12 Feb '19

Greetings, I am getting inconsistent results and could use some help. The FFI tests pass green on aarch64 on Samsung Chromebook Plus/Linux and LePotato/Linux. However, in Raspberry Pi 3 [ArchLinuxArm=linux/aarch64] and an old x86_64 Ubuntu Linux machine I get matching failures: - 2 FFI unit tests in Cuis5.0-3589 - Total breakage in Squeak5.2-18229-64bit In each case I am using locally built VMs with the same code from git. The Cuis case is interesting in that the failure cases are the same for aarch64 and x86_64: - FFIPluginTest>>#testGenericDoubleCall2 - FFIPluginTest>>#testMixedDoublesIntAndStruct The other test cases pass. In each case a double result is properly returned (gdb) but I get lost in gcc3x_interp.c floatObjectOf() details. The Squeak case which passes green on SChromebookPlus & LePotato has Monticello versions FFI-Kernel (eem.56) FFI-Tests (KenD.1 in source.squeak.org inbox; else cbc.9) FFI-Pools (TorstenBergmann.4) FFI-Unix (mtf.4) Again these tests fail (32 errors; 1 failure) on Raspi3 and x86_64 Linux systems. gcc versions: SChromebookPlus: 6.8.0 x86 Ubuntu: 7.3.0 RasPi3 ArchLinuxArm: 8.2.1 I used build.linux64x64/squeak.cog.spur/build for x86 I used build.linux64ARMv8/squeak.stack.spur/build for aarch64 Any brave souls out there? Thanks much for any help with this, -KenD

1 0

VM Maker: ImageFormat-dtl.33.mcz
by commits＠source.squeak.org 11 Feb '19

11 Feb '19

David T. Lewis uploaded a new version of ImageFormat to project VM Maker: http://source.squeak.org/VMMaker/ImageFormat-dtl.33.mcz ==================== Summary ==================== Name: ImageFormat-dtl.33 Author: dtl Time: 10 February 2019, 6:07:34.977 pm UUID: 4003ca6e-3b44-46e4-9c98-55b3ec8e3901 Ancestors: ImageFormat-dtl.31 Refactor instance creation to allow image header instances to be created from a stream or array of header field values in addition to the traditional read from file stream on the image file. Add hooks for hypothetical primitives to answer header filelds directly from the VM. =============== Diff against ImageFormat-dtl.31 =============== Item was added: + ----- Method: CogImageFileHeader>>fromEntryStream: (in category 'reading') ----- + fromEntryStream: streamOfHeaderStateObjects + + super fromEntryStream: streamOfHeaderStateObjects. + desiredNumStackPages := streamOfHeaderStateObjects next. + unknownShortOrCodeSizeInKs := streamOfHeaderStateObjects next. + desiredEdenBytes := streamOfHeaderStateObjects next. + maxExtSemTabSizeSet := streamOfHeaderStateObjects next. + ! Item was removed: - ----- Method: CogImageFileHeader>>readFieldsFrom:startingAt:headerWordSize:littleEndian: (in category 'reading') ----- - readFieldsFrom: aStream startingAt: imageOffset headerWordSize: headerWordSize littleEndian: littleEndian - "Read data fields and answer number of bytes read" - - | remainder bytesRead | - bytesRead := super readFieldsFrom: aStream startingAt: imageOffset headerWordSize: headerWordSize littleEndian: littleEndian. - desiredNumStackPages := self nextNumber: headerWordSize / 2 from: aStream littleEndian: littleEndian. - unknownShortOrCodeSizeInKs := self nextNumber: headerWordSize / 2 from: aStream littleEndian: littleEndian. - desiredEdenBytes := self nextNumber: headerWordSize from: aStream littleEndian: littleEndian. - maxExtSemTabSizeSet := self nextNumber: headerWordSize / 2 from: aStream littleEndian: littleEndian. - self nextNumber: headerWordSize / 2 from: aStream littleEndian: littleEndian. - remainder := headerSize - (12 * imageFormat wordSize). - self assert: remainder >= 0. "n.b. Mantis 7455 bug in original 64 bit image due to VMM error" - ^3 * imageFormat wordSize + bytesRead. - ! Item was added: + ----- Method: CogImageFileHeader>>readFieldsFrom:startingAt:headerWordSize:littleEndian:into: (in category 'reading') ----- + readFieldsFrom: aStream startingAt: imageOffset headerWordSize: headerWordSize littleEndian: littleEndian into: aCollection + "Read data fields and answer number of bytes read" + + | remainder bytesRead | + bytesRead := super readFieldsFrom: aStream startingAt: imageOffset headerWordSize: headerWordSize littleEndian: littleEndian into: aCollection. + aCollection add: (self nextNumber: headerWordSize / 2 from: aStream littleEndian: littleEndian). "desiredNumStackPages" + aCollection add: (self nextNumber: headerWordSize / 2 from: aStream littleEndian: littleEndian). "unknownShortOrCodeSizeInKs" + aCollection add: (self nextNumber: headerWordSize from: aStream littleEndian: littleEndian). "desiredEdenBytes" + aCollection add: (self nextNumber: headerWordSize / 2 from: aStream littleEndian: littleEndian). "maxExtSemTabSizeSet" + self nextNumber: headerWordSize / 2 from: aStream littleEndian: littleEndian. + remainder := headerSize - (12 * imageFormat wordSize). + self assert: remainder >= 0. "n.b. Mantis 7455 bug in original 64 bit image due to VMM error" + ^3 * imageFormat wordSize + bytesRead. + ! Item was added: + ----- Method: ImageFileHeader class>>fromValues: (in category 'instance creation') ----- + fromValues: headerValues + "Answer an new instance initialized from an array of values corresponding to + fields in an image file header on disk. The values may have been read from a + file, or they may have been created by querying the running VM." + + "self fromValues:self primInterpreterStateSnapshot" + + ^self basicNew fromEntryStream: headerValues readStream + ! Item was added: + ----- Method: ImageFileHeader class>>primInterpreterStateSnapshot (in category 'primitive access') ----- + primInterpreterStateSnapshot + "Answer an array of values suitable for creating an image file header" + + "ImageFileHeader primInterpreterStateSnapshot" + + "ImageFileHeader fromValues: ImageFileHeader primInterpreterStateSnapshot" + + <primitive: 'primitiveInterpreterStateSnapshot'> + self primitiveFailed! Item was added: + ----- Method: ImageFileHeader class>>primMemoryCopy (in category 'primitive access') ----- + primMemoryCopy + "Answer an exact copy of the current object memory" + + "ImageFileHeader primMemoryCopy" + + <primitive: 'primitiveMemoryCopy'> + self primitiveFailed! Item was added: + ----- Method: ImageFileHeader class>>primMemorySnapshotWithHeader (in category 'primitive access') ----- + primMemorySnapshotWithHeader + "Answer an array with a snapshot of the object memory, and with an interpreter + state array of values suitable for creating an image file header. This is an atomic + request for primitiveMemorySnapshot and primitiveInterpreterStateSnapshot." + + "ImageFileHeader primMemorySnapshotWithHeader" + + " | result | + result := ImageFileHeader primMemorySnapshotWithHeader. + { result first . ImageFileHeader fromValues: result second } " + + <primitive: 'primitiveMemorySnapshotWithHeader'> + self primitiveFailed! Item was changed: ----- Method: ImageFileHeader class>>readFrom: (in category 'instance creation') ----- readFrom: aStream ^self readFrom: aStream startingAt: 0! Item was changed: ----- Method: ImageFileHeader class>>readFrom:startingAt: (in category 'instance creation') ----- readFrom: aStream startingAt: imageOffset + ^self basicNew readFrom: aStream startingAt: imageOffset into: OrderedCollection new! - ^self basicNew readFrom: aStream startingAt: imageOffset! Item was added: + ----- Method: ImageFileHeader>>= (in category 'comparing') ----- + = other + + self species == other species ifFalse: [^ false]. + 1 to: self class instSize do: + [:i | (self instVarAt: i) = (other instVarAt: i) ifFalse: [^ false]]. + ^ true! Item was added: + ----- Method: ImageFileHeader>>asValues (in category 'converting') ----- + asValues + "Answer an array of values from which a copy of this instance could be + created with #fromValues:" + + "self fromValues: (self fromValues:self primInterpreterStateSnapshot) asValues" + + ^Array new writeStream + nextPut: imageFormat asInteger; + nextPut: headerSize; + nextPut: imageBytes; + nextPut: startOfMemory; + nextPut: specialObjectsOop; + nextPut: lastHash; + nextPut: screenSize; + nextPut: imageHeaderFlags; + nextPut: extraVMMemory; + contents + ! Item was added: + ----- Method: ImageFileHeader>>fromEntryStream: (in category 'reading') ----- + fromEntryStream: streamOfHeaderStateObjects + + imageFormat := ImageFormat fromInteger: streamOfHeaderStateObjects next. + headerSize := streamOfHeaderStateObjects next. + imageBytes := streamOfHeaderStateObjects next. + startOfMemory := streamOfHeaderStateObjects next. + specialObjectsOop := streamOfHeaderStateObjects next. + lastHash := streamOfHeaderStateObjects next. + screenSize := streamOfHeaderStateObjects next. "a Point with two integer values for X and Y extent" + imageHeaderFlags := streamOfHeaderStateObjects next. + extraVMMemory := streamOfHeaderStateObjects next. + + ! Item was added: + ----- Method: ImageFileHeader>>hash (in category 'comparing') ----- + hash + ^imageBytes hash xor: lastHash! Item was removed: - ----- Method: ImageFileHeader>>readFieldsFrom:startingAt:headerWordSize:littleEndian: (in category 'reading') ----- - readFieldsFrom: aStream startingAt: imageOffset headerWordSize: headerWordSize littleEndian: littleEndian - "Read data fields and answer number of bytes read" - - | remainder screenSizeWord | - headerSize := self nextNumber: headerWordSize from: aStream littleEndian: littleEndian. - imageBytes := self nextNumber: headerWordSize from: aStream littleEndian: littleEndian. - startOfMemory := self nextNumber: headerWordSize from: aStream littleEndian: littleEndian. - specialObjectsOop := self nextNumber: headerWordSize from: aStream littleEndian: littleEndian. - lastHash := self nextNumber: headerWordSize from: aStream littleEndian: littleEndian. - screenSizeWord := self nextNumber: headerWordSize from: aStream littleEndian: littleEndian. - screenSize := (screenSizeWord >> 16) @ (screenSizeWord bitAnd: 16rFFFF). - imageHeaderFlags := self nextNumber: headerWordSize from: aStream littleEndian: littleEndian. - extraVMMemory := self nextNumber: headerWordSize from: aStream littleEndian: littleEndian. - remainder := headerSize - (9 * imageFormat wordSize). - self assert: remainder >= 0. "n.b. Mantis 7455 bug in original 64 bit image due to VMM error" - ^9 * imageFormat wordSize. - ! Item was added: + ----- Method: ImageFileHeader>>readFieldsFrom:startingAt:headerWordSize:littleEndian:into: (in category 'reading') ----- + readFieldsFrom: aStream startingAt: imageOffset headerWordSize: headerWordSize littleEndian: littleEndian into: aCollection + "Read data fields and answer number of bytes read" + + | remainder screenSizeWord | + headerSize := self nextNumber: headerWordSize from: aStream littleEndian: littleEndian. + aCollection add: headerSize. + aCollection add: ( self nextNumber: headerWordSize from: aStream littleEndian: littleEndian). "imageBytes" + aCollection add: (self nextNumber: headerWordSize from: aStream littleEndian: littleEndian). "startOfMemory" + aCollection add: (self nextNumber: headerWordSize from: aStream littleEndian: littleEndian). "specialObjectsOop" + aCollection add: (self nextNumber: headerWordSize from: aStream littleEndian: littleEndian). "lastHash" + screenSizeWord := self nextNumber: headerWordSize from: aStream littleEndian: littleEndian. + aCollection add: ((screenSizeWord >> 16) @ (screenSizeWord bitAnd: 16rFFFF)). + aCollection add: (self nextNumber: headerWordSize from: aStream littleEndian: littleEndian). "imageHeaderFlags" + aCollection add: (self nextNumber: headerWordSize from: aStream littleEndian: littleEndian). "extraVMMemory" + remainder := headerSize - (9 * imageFormat wordSize). + self assert: remainder >= 0. "n.b. Mantis 7455 bug in original 64 bit image due to VMM error" + ^9 * imageFormat wordSize. + ! Item was removed: - ----- Method: ImageFileHeader>>readFrom:startingAt: (in category 'reading') ----- - readFrom: aStream startingAt: imageOffset - - | remainder bytesRead headerWordSize littleEndian | - littleEndian := self readImageVersionFrom: aStream startingAt: imageOffset. - headerWordSize := aStream position - imageOffset. - bytesRead := self readFieldsFrom: aStream startingAt: imageOffset headerWordSize: headerWordSize littleEndian: littleEndian. - remainder := headerSize - bytesRead. - self assert: remainder >= 0. "n.b. Mantis 7455 bug in original 64 bit image due to VMM error" - aStream next: (headerSize - bytesRead). - ! Item was added: + ----- Method: ImageFileHeader>>readFrom:startingAt:into: (in category 'reading') ----- + readFrom: aStream startingAt: imageOffset into: aCollection + + | remainder bytesRead headerWordSize littleEndian | + littleEndian := self readImageVersionFrom: aStream startingAt: imageOffset. + headerWordSize := aStream position - imageOffset. + aCollection add: imageFormat asInteger. + bytesRead := self readFieldsFrom: aStream startingAt: imageOffset headerWordSize: headerWordSize littleEndian: littleEndian into: aCollection. + remainder := headerSize - bytesRead. + self assert: remainder >= 0. "n.b. Mantis 7455 bug in original 64 bit image due to VMM error" + aStream next: (headerSize - bytesRead). + + self fromEntryStream: aCollection readStream. + ! Item was added: + ----- Method: ImageFormat>>= (in category 'comparing') ----- + = anImageFormat + ^self class == anImageFormat class + and: [self asInteger = anImageFormat asInteger]. + ! Item was added: + ----- Method: ImageFormat>>hash (in category 'comparing') ----- + hash + ^self asInteger hash!

1 0

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev February 2019