Vm-dev June 2016

vm-dev@lists.squeakfoundation.org

50 participants
129 discussions

Re: [Vm-dev] build emergency with recent changes to updateSCCSVersions
by Jakob Reschke 22 Jun '16

22 Jun '16

2016-06-22 0:00 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > So where should one put the git config command? You should run it only once. git config reads and edits settings for you; git config --global edits your ~/.gitconfig file. If you like, you can edit the file directly instead.

1 0

build emergency with recent changes to updateSCCSVersions
by Eliot Miranda 22 Jun '16

22 Jun '16

Hi All, recent changes, I *think* to updateSCCSVersions, have broken platforms/Cross/vm/sqSCCSVersion.h: static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin) tim/deployment-fixes new (next fetch will store in remotes/origin) $"; First, multi-liner string constants must be terminated with a backslash to compile. So at the very least we'd need static char SvnRawRepositoryURL[] = "$URL: http://github.com/OpenSmalltalk/vm\ SetWindowLongPtr_64bit_compatibility new (next fetch will store in remotes/origin)\ tim/deployment-fixes new (next fetch will store in remotes/origin) $"; But second, multi-line output doesn't make sense here. We need something that fits on a single line. Who is going to fix this? I have a production build which is broken because of this. _,,,^..^,,,_ best, Eliot

4 8

Re: System and user processe
by Max Leske 21 Jun '16

21 Jun '16

>> Message: 17 >> Date: Tue, 21 Jun 2016 00:33:17 -0700 (PDT) >> From: "marcel.taeumel" <Marcel.Taeumel(a)hpi.de> >> Subject: [squeak-dev] Re: [Vm-dev] System and user processes >> To: squeak-dev(a)lists.squeakfoundation.org >> Message-ID: <1466494397918-4902025.post(a)n4.nabble.com> >> Content-Type: text/plain; charset=UTF-8 >> >> Chris Muller-3 wrote >> Hi Max, I had a similar idea, and made a ClientProcess class. Its >> primary purpose is to provide a nice wrapping API for *users* to >> manage their "background running tasks" (i.e., #start, #stop, #pause, >> #resume, #progress, #priority adjustment), as well as a nice API for >> *developers* to report its progress via a simple signaling mechanism, >> which also gives the user all the performance stats for "free" too >> like #unitsCompleted, #runningTime, #ratePerSecond, #remainingTime, >> etc. >> >> On Sun, Jun 19, 2016 at 4:03 AM, Max Leske < >> >> maxleske@ >> >> > wrote: >> >> Hi, >> >> In Pharo and Squeak we have no separation between processes that belong >> to the IDE, tools etc. and processes that are spawned as part of an >> application. I’d like to know your opinion on the following (rough) idea: >> >> 1. We introduce two subclasses of Process: SystemProcess and UserProcess >> 2. We define #isSystemProcess and #isUserProcess >> 3. We introduce #newSystemProcess and #newUserProcess >> 4. We deprecate #newProcess and delegate to #newUserProcess (thereby >> modifying all users of #forkXXX to yield instances of UserProcess) >> >> Of the following I’m less sure: >> 5. We introduce #forkSystemProcess et. al >> >> I’ve tried this out in Pharo 6 and there seem to be no problems with the >> VM. The benefit would be improved separation between system and user >> space. It would allow us to implement stuff for processes in general >> (e.g. for the debugger) which we do not want to affect system processes >> like the UI process or the background process. One concrete example: the >> process browser could hide all system processes and make them visible on >> demand (that would greatly improve the view because you can now better >> find your own processes). >> >> >> I’m looking forward to your comments. >> >> Cheers, >> Max > > Hi Chris, > > Hmm... I would implement such an API rather via composition than > inheritance. Such a task does not necessarily have to run in the same image > but could also be accomplished on another machine. OSProcess has RemoteTask > for this. Inheritance would make things complicated once one would decide to > not carry out the computation as a Squeak process. > > I do like Tony's idea of process groups. We could think this one step > further an add multiple tags (symbols?) to processes to support > fine-granular or cross-cutting classifications. Tools like the process > browser could show these tags, group by them, etc. There could be tags to > identify processes that would stop working once you close the Squeak image > (e.g. "not resumable")... Hmmm... Application developers could use tags to > provide hints for other developers and users. > > Best, > Marcel Good point. Inheritance is nice but as for our infamous stream hierarchy processes would probably need to be grouped by different traits. But I think that groups and tags may be two different things. Tony’s “current process group” for instance would have to implemented as a special tag already, unless a new process simply inherited all tags. In Pharo (I don’t know about Squeak) we now have a session manager that can be asked if the current session has changed, i.e. whether the image has been restarted. Now, instead of checking in with the session manager explicitly I could use a “session dependant” process, which terminates when the session changes. Cheers, Max

3 2

git mavens, shortcut please?
by Eliot Miranda 21 Jun '16

21 Jun '16

Hi All, I find myself in this situation a lot: Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: platforms/Cross/plugins/IA32ABI/ia32abi.h modified: platforms/Cross/plugins/IA32ABI/x64ia32abicc.c modified: platforms/Cross/plugins/IA32ABI/xabicc.c Untracked files: (use "git add <file>..." to include in what will be committed) platforms/Cross/plugins/IA32ABI/.ia32abicc.c.swp What's the one liner to add the modified files and ignore the untracked files? What's the one-liner to add and commit the modified files and ignore the untracked files? [hate the word "add" being used to mean "stage". This thing was written by a sadist]. _,,,^..^,,,_ best, Eliot

7 9

Re: System and user processe
by Max Leske 21 Jun '16

21 Jun '16

>> On 06/19/2016 05:03 AM, Max Leske wrote: >> Hi, >> >> In Pharo and Squeak we have no separation between processes that >> belong to the IDE, tools etc. and processes that are spawned as part >> of an application. I’d like to know your opinion on the following >> (rough) idea: >> >> 1. We introduce two subclasses of Process: SystemProcess and >> UserProcess 2. We define #isSystemProcess and #isUserProcess 3. We >> introduce #newSystemProcess and #newUserProcess 4. We deprecate >> #newProcess and delegate to #newUserProcess (thereby modifying all >> users of #forkXXX to yield instances of UserProcess) >> >> Of the following I’m less sure: 5. We introduce #forkSystemProcess >> et. al >> >> I’ve tried this out in Pharo 6 and there seem to be no problems with >> the VM. The benefit would be improved separation between system and >> user space. It would allow us to implement stuff for processes in >> general (e.g. for the debugger) which we do not want to affect system >> processes like the UI process or the background process. One concrete >> example: the process browser could hide all system processes and make >> them visible on demand (that would greatly improve the view because >> you can now better find your own processes). >> >> >> I’m looking forward to your comments. >> >> Cheers, Max >> >> >> >> On Tue, Jun 21, 2016 at 3:32 AM, Tony Garnock-Jones <tonyg(a)ccs.neu.edu> wrote: >> Hi Max, >> >> Perhaps a notion of process grouping might make sense? Following the >> zero-one-infinity principle, having exactly two kinds of process seems a >> bit odd. >> >> Having process grouping would lead to a tree of processes. >> >> For example, the outermost level could be "system" processes, of which >> one was a group containing all "user" processes. >> >> Or, the outermost level could have two children, one group of "system" >> procs, one of "user" procs; or, ... >> >> The "current process group" would be a kind of dynamic parameter, and >> newly-forked processes would by default become siblings of the forker in >> the current group. >> >> Regards, >> Tony > > This sounds like a good idea. It would make it easier for a user of > multiple applications in one image to properly kill one. For this > reason, perhaps there should be some impediment on apps adding > processes adding the System Process group(??) > > cheers -ben Yes. That’s why in my proposal the default is to create a user process. Cheers, Max

1 0

Re: System and user processe
by Max Leske 21 Jun '16

21 Jun '16

> Hi Max, > > Perhaps a notion of process grouping might make sense? Following the > zero-one-infinity principle, having exactly two kinds of process seems a > bit odd. I agree. I just wanted to get the idea out there without proposing a complete POSIX process model. And I found it interesting that we actually could use subclasses without needing special support from the VM. > > Having process grouping would lead to a tree of processes. > > For example, the outermost level could be "system" processes, of which > one was a group containing all "user" processes. > > Or, the outermost level could have two children, one group of "system" > procs, one of "user" procs; or, ... > > The "current process group" would be a kind of dynamic parameter, and > newly-forked processes would by default become siblings of the forker in > the current group. > > Regards, > Tony I think that grouping makes a lot of sense. However, the current model has also served us well, maybe exactly because it is simple. Adding a lot of complexity will not necessarily make things better (especially for newcomers). Maybe there’s a middle ground where high level processes maintain a very simple API (like Chris proposed) and where you don’t have to know about process groups (those processes might just go into a default group, essentially what you describe with “current process group"). Really not sure… Cheers, Max > > > > On 06/19/2016 05:03 AM, Max Leske wrote: > Hi, > > In Pharo and Squeak we have no separation between processes that > belong to the IDE, tools etc. and processes that are spawned as part > of an application. I’d like to know your opinion on the following > (rough) idea: > > 1. We introduce two subclasses of Process: SystemProcess and > UserProcess 2. We define #isSystemProcess and #isUserProcess 3. We > introduce #newSystemProcess and #newUserProcess 4. We deprecate > #newProcess and delegate to #newUserProcess (thereby modifying all > users of #forkXXX to yield instances of UserProcess) > > Of the following I’m less sure: 5. We introduce #forkSystemProcess > et. al > > I’ve tried this out in Pharo 6 and there seem to be no problems with > the VM. The benefit would be improved separation between system and > user space. It would allow us to implement stuff for processes in > general (e.g. for the debugger) which we do not want to affect system > processes like the UI process or the background process. One concrete > example: the process browser could hide all system processes and make > them visible on demand (that would greatly improve the view because > you can now better find your own processes). > > > I’m looking forward to your comments. > > Cheers, Max

1 0

Re: System and user processe
by Max Leske 21 Jun '16

21 Jun '16

> Max Leske wrote >> Hi, >> >> In Pharo and Squeak we have no separation between processes that belong to >> the IDE, tools etc. and processes that are spawned as part of an >> application. I’d like to know your opinion on the following (rough) idea: >> >> 1. We introduce two subclasses of Process: SystemProcess and UserProcess >> 2. We define #isSystemProcess and #isUserProcess >> 3. We introduce #newSystemProcess and #newUserProcess >> 4. We deprecate #newProcess and delegate to #newUserProcess (thereby >> modifying all users of #forkXXX to yield instances of UserProcess) >> >> Of the following I’m less sure: >> 5. We introduce #forkSystemProcess et. al >> >> I’ve tried this out in Pharo 6 and there seem to be no problems with the >> VM. The benefit would be improved separation between system and user >> space. It would allow us to implement stuff for processes in general (e.g. >> for the debugger) which we do not want to affect system processes like the >> UI process or the background process. One concrete example: the process >> browser could hide all system processes and make them visible on demand >> (that would greatly improve the view because you can now better find your >> own processes). >> >> >> I’m looking forward to your comments. >> >> Cheers, >> Max > > Hi Max, > > I like the idea. Let's see... > > System processes in Squeak could be: > - the timer interrupt watcher > - the event tickler > - the low space watcher > - the user interrupt watcher > - the idle process > > I am not so sure about: > - the WeakArray finalization process (still needed for Ephemerons?) > > Then we have the UI framework(s). The frameworks' processes could be user > processes or system processes, too? Hmm... for Morphic, there is only one. > Stepping is implemented with the same UI process. Applications that spawn > other (user) processes work around Morphic anyway. > > Tweak uses (or used) many processes to execute scripts. So, the Tweak UI has > a set of related processes, not just a single UI process. > > MVC has only one process running but creates/terminates processes when > switching controllers. > > If you play a MIDI or a Sound, should that process also be a system process, > right? Hmm... > > Interactive debugging is tricky only with respect to the current UI > framework because you want to be able to also debug that frameworks code and > its applications. While writing the debugger in that framework, too. So, it > is above the level of processes but at the level of the UI framework (resp. > projects). At least in Squeak. > > Hmm... for a filter in the process browser, a simple flag would be enough. > No need to add subclasses. So, whout be the benefits of distinguishing > between UserProcess and SystemProcess at process creation time? How to > decide? Might it be related to additional warnings? Calling "Smalltalk > snapshot: true andQuit: true" from a process in an endless loop might be > detected if you do that from within a UserProcess. :-D > > Maybe introduce restrictions/warnings at the level of message dispatch for > UserProcesses? Hmm… You essentially get my point. For the process browser a flag would be enough, yes, but that’s not really OO, is it… :) Anyway, I see a couple of “direct” benefits: - better implementation of user interrupt handling (user processes can always be interrupted) - kill all user processes (system will keep running) - different low space settings for system and user processes (yes, that would probably require a VM change, but still…) - system processes could be prevented from starving (e.g. a user process must yield at least every n milliseconds) ... > > Best, > Marcel > >

1 0

System and user processes
by Max Leske 21 Jun '16

21 Jun '16

Hi, In Pharo and Squeak we have no separation between processes that belong to the IDE, tools etc. and processes that are spawned as part of an application. I’d like to know your opinion on the following (rough) idea: 1. We introduce two subclasses of Process: SystemProcess and UserProcess 2. We define #isSystemProcess and #isUserProcess 3. We introduce #newSystemProcess and #newUserProcess 4. We deprecate #newProcess and delegate to #newUserProcess (thereby modifying all users of #forkXXX to yield instances of UserProcess) Of the following I’m less sure: 5. We introduce #forkSystemProcess et. al I’ve tried this out in Pharo 6 and there seem to be no problems with the VM. The benefit would be improved separation between system and user space. It would allow us to implement stuff for processes in general (e.g. for the debugger) which we do not want to affect system processes like the UI process or the background process. One concrete example: the process browser could hide all system processes and make them visible on demand (that would greatly improve the view because you can now better find your own processes). I’m looking forward to your comments. Cheers, Max

2 2

VM Maker: VMMaker.oscog-eem.1889.mcz
by commits＠source.squeak.org 20 Jun '16

20 Jun '16

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1889.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1889 Author: eem Time: 20 June 2016, 1:33:14.0061 pm UUID: 24dcf481-d07a-4e68-a4bf-7d6d8ce2ae4f Ancestors: VMMaker.oscog-eem.1888 Fix a bug in Spur become validation, a regression from supporting copyHash properly. The check for there being available memroy for copies of all arguments should only occur in the two-way case, not in the one-way copyHash case. Refactor Clément's checker into ifOopInvalidForBecome:errorCodeInto: and use it to check all checked arguments. This fixes Bert's (ByteString new: 20000000) writeStream nextPut: (Character value: 128169) case. In 1889 Herman Hollerith receives a patent for his electric tabulating machine in the United States, Vincent van Gogh paints The Starry Night at Saint-Rémy-de-Provence, and the Eiffel Tower is inaugurated and opens on May 6. At 300 m, its height exceeds the previous tallest structure in the world by 130 m. =============== Diff against VMMaker.oscog-eem.1888 =============== Item was changed: ----- Method: SpurMemoryManager>>become:with:twoWay:copyHash: (in category 'become api') ----- become: array1 with: array2 twoWay: twoWayFlag copyHash: copyHashFlag "All references to each object in array1 are swapped with all references to the corresponding object in array2. That is, all pointers to one object are replaced with with pointers to the other. The arguments must be arrays of the same length. Answers PrimNoErr if the primitive succeeds, otherwise a relevant error code." "Implementation: Uses lazy forwarding to defer updating references until message send." + <inline: false> | ec | self assert: becomeEffectsFlags = 0. self runLeakCheckerFor: GCModeBecome. (self isArray: array1) ifFalse: [^PrimErrBadReceiver]. ((self isArray: array2) and: [(self numSlotsOf: array1) = (self numSlotsOf: array2)]) ifFalse: [^PrimErrBadArgument]. + ec := self containsOnlyValidBecomeObjects: array1 and: array2 twoWay: twoWayFlag copyHash: copyHashFlag. - (twoWayFlag or: [copyHashFlag]) - ifTrue: - [ec := self containsOnlyValidBecomeObjects: array1 and: array2] - ifFalse: - [self followForwardedObjectFields: array2 toDepth: 0. - ec := self containsOnlyValidBecomeObjects: array1]. ec ~= 0 ifTrue: [becomeEffectsFlags := 0. ^ec]. coInterpreter preBecomeAction. twoWayFlag ifTrue: [self innerBecomeObjectsIn: array1 and: array2 copyHash: copyHashFlag] ifFalse: [self innerBecomeObjectsIn: array1 to: array2 copyHash: copyHashFlag]. self followSpecialObjectsOop. "N.B. perform coInterpreter's postBecomeAction: *before* postBecomeScanClassTable: to allow the coInterpreter to void method cache entries by spotting classIndices that refer to forwarded objects. postBecomeScanClassTable: follows forwarders in the table." coInterpreter postBecomeAction: becomeEffectsFlags. self postBecomeScanClassTable: becomeEffectsFlags. becomeEffectsFlags := 0. self assert: self validClassTableHashes. self runLeakCheckerFor: GCModeBecome. ^PrimNoErr "success"! Item was removed: - ----- Method: SpurMemoryManager>>containsOnlyValidBecomeObjects: (in category 'become implementation') ----- - containsOnlyValidBecomeObjects: array - "Answer 0 if the array contains only unpinned non-immediates. - Otherwise answer an informative error code. - Can't become: immediates!! Shouldn't become pinned objects." - | fieldOffset effectsFlags oop errCode | - fieldOffset := self lastPointerOfArray: array. - effectsFlags := 0. - "same size as array2" - [fieldOffset >= self baseHeaderSize] whileTrue: - [oop := self longAt: array + fieldOffset. - (self isOopForwarded: oop) ifTrue: - [oop := self followForwarded: oop. - self longAt: array + fieldOffset put: oop]. - (errCode := self isOopValidBecome: oop) = 0 ifFalse: [^ errCode]. - effectsFlags := effectsFlags bitOr: (self becomeEffectFlagsFor: oop). - fieldOffset := fieldOffset - self bytesPerOop]. - "only set flags after checking all args." - becomeEffectsFlags := effectsFlags. - ^0! Item was removed: - ----- Method: SpurMemoryManager>>containsOnlyValidBecomeObjects:and: (in category 'become implementation') ----- - containsOnlyValidBecomeObjects: array1 and: array2 - "Answer 0 if neither array contains only unpinned non-immediates. - Otherwise answer an informative error code. - Can't become: immediates!! Shouldn't become pinned objects." - | fieldOffset effectsFlags oop size | - fieldOffset := self lastPointerOf: array1. - effectsFlags := size := 0. - "same size as array2" - [fieldOffset >= self baseHeaderSize] whileTrue: - [oop := self longAt: array1 + fieldOffset. - (self isOopForwarded: oop) ifTrue: - [oop := self followForwarded: oop. - self longAt: array1 + fieldOffset put: oop]. - (self isImmediate: oop) ifTrue: [^PrimErrInappropriate]. - (self isPinned: oop) ifTrue: [^PrimErrObjectIsPinned]. - effectsFlags := effectsFlags bitOr: (self becomeEffectFlagsFor: oop). - size := size + (self bytesInObject: oop). - oop := self longAt: array2 + fieldOffset. - (self isOopForwarded: oop) ifTrue: - [oop := self followForwarded: oop. - self longAt: array2 + fieldOffset put: oop]. - (self isImmediate: oop) ifTrue: [^PrimErrInappropriate]. - (self isPinned: oop) ifTrue: [^PrimErrObjectIsPinned]. - effectsFlags := effectsFlags bitOr: (self becomeEffectFlagsFor: oop). - size := size + (self bytesInObject: oop). - fieldOffset := fieldOffset - self bytesPerOop]. - size >= (totalFreeOldSpace + (scavengeThreshold - freeStart)) ifTrue: - [^PrimErrNoMemory]. - "only set flags after checking all args." - becomeEffectsFlags := effectsFlags. - ^0! Item was added: + ----- Method: SpurMemoryManager>>containsOnlyValidBecomeObjects:and:twoWay:copyHash: (in category 'become implementation') ----- + containsOnlyValidBecomeObjects: array1 and: array2 twoWay: isTwoWay copyHash: copyHash + "Answer 0 if neither array contains an object inappropriate for the become operation. + Otherwise answer an informative error code for the first offending object found: + Can't become: immediates => PrimErrInappropriate + Shouldn't become pinned objects => PrimErrObjectIsPinned. + Shouldn't become immutable objects => PrimErrNoModification. + Can't copy hash into immediates => PrimErrInappropriate. + Two-way become may require memory to create copies => PrimErrNoMemory. + As a side-effect unforward any forwarders in the two arrays if answering 0." + <inline: true> + | fieldOffset effectsFlags oop1 oop2 size | + fieldOffset := self lastPointerOf: array1. + effectsFlags := size := 0. + "array1 is known to be the same size as array2" + [fieldOffset >= self baseHeaderSize] whileTrue: + [oop1 := self longAt: array1 + fieldOffset. + (self isOopForwarded: oop1) ifTrue: + [oop1 := self followForwarded: oop1. + self longAt: array1 + fieldOffset put: oop1]. + self ifOopInvalidForBecome: oop1 errorCodeInto: [:errCode| ^errCode]. + effectsFlags := effectsFlags bitOr: (self becomeEffectFlagsFor: oop1). + oop2 := self longAt: array2 + fieldOffset. + (self isOopForwarded: oop2) ifTrue: + [oop2 := self followForwarded: oop2. + self longAt: array2 + fieldOffset put: oop2]. + isTwoWay + ifTrue: + [self ifOopInvalidForBecome: oop2 errorCodeInto: [:errCode| ^errCode]. + size := size + (self bytesInObject: oop1) + (self bytesInObject: oop2). + effectsFlags := effectsFlags bitOr: (self becomeEffectFlagsFor: oop2)] + ifFalse: + [(copyHash and: [self isImmediate: oop2]) ifTrue: + [^PrimErrInappropriate]]. + fieldOffset := fieldOffset - self bytesPerOop]. + size >= (totalFreeOldSpace + (scavengeThreshold - freeStart)) ifTrue: + [^PrimErrNoMemory]. + "only set flags after checking all args." + becomeEffectsFlags := effectsFlags. + ^0! Item was added: + ----- Method: SpurMemoryManager>>ifOopInvalidForBecome:errorCodeInto: (in category 'become implementation') ----- + ifOopInvalidForBecome: oop errorCodeInto: aBlock + "Evaluates aBlock with an appropriate error if oop is invalid for become." + <inline: true> + (self isImmediate: oop) ifTrue: + [^aBlock value: PrimErrInappropriate]. + (self isPinned: oop) ifTrue: + [^aBlock value: PrimErrObjectIsPinned]. + (self isObjImmutable: oop) ifTrue: + [^aBlock value: PrimErrNoModification]! Item was removed: - ----- Method: SpurMemoryManager>>isOopValidBecome: (in category 'become implementation') ----- - isOopValidBecome: oop - "Answers 0 if the oop can be become. - Answers an error code in the other case" - (self isImmediate: oop) ifTrue: [^PrimErrInappropriate]. - (self isPinned: oop) ifTrue: [^PrimErrObjectIsPinned]. - (self isObjImmutable: oop) ifTrue: [^PrimErrNoModification]. - ^0!

1 0

Re: [Pharo-dev] [Vm-dev] Methods with more than 15 args sketch
by Clément Bera 20 Jun '16

20 Jun '16

Hi, I think there was a misunderstanding Tim. The idea is not necessarily to let developers write code with this many arguments, the IDE could actually enforces the programmer not to write methods with too many arguments. It's really about non programmers, like code generating tools such as SmaCC. In Java for example, the "Clean code" code convention limits the number of arguments per method to 3, the "Code complete" code convention limits it to 7, but Java can compile methods up to 255 arguments for code generators. If you want to limit the number of arguments the programmer can write, enforce it in the IDE according to your code convention. *Please talk about the maximum number of arguments a developer can write in another thread, this is non related to the implementation discussed here.* As Jan said, there are already too many limitations in Smalltalk to write proper code generators. We've worked on those limitations already: - the SistaV1 bytecode set will go to production in Pharo 6 (likely Squeak at some point too) and it removes an important part of the limitations (jump sizes up to 65k instructions instead of 1024, ...). - Spur removed other limitations (methods with up to 32k literals instead of 255, behaviors with up to 65k inst vars instead of 255). The important limitations remaining are the max frame size (56), which in practice limits the number of temps to around 55, whereas we could have 64 temps or more, and the number of arguments of methods and blocks. This scheme is about solving those problems. There are 0.5% of methods using a large frame so we could grow from 56 to 128 or 256 without any significant problems. For arguments bytecode calling convention looks so much simpler than VM support. On Mon, Jun 20, 2016 at 8:30 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 19 Jun 2016, at 11:35, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > > Does anyone want to pick this up on the Pharo image side? > > > > I took a brief look at this and while playing I noticed that the errors > when we send more than 15 arguments seem a bit strange. Take a look at this > snippet: > > http://ws.stfx.eu/958BXP5GR136 > > (you can paste it in Spotter to get the playground) > > > > In summary: > > - If we compile a method with a signature containing more than 15 > arguments we get: > > "SyntaxErrorNotification: Too many arguments’”. > > This is good. > > > > - If we compile a method with a message send containing between 16-31 > arguments we get: > > "'InMidstOfFileinNotification’”. > > Ok-ish. > > > > - If we compile a method with a message send containing more than 31 > arguments we get: > > "'Error: genSend:numArgs: numArgs index 32 is out of range 0 to > 31’" > > This is wrong. > > > > > > Did I misunderstand something? > > > > The VM does not support it, and as nobody is using it, the error messages > are not that perfect. > (to have them nicer, someone would have seen it and be bothered to fix it…) > > What Clement proposes is to implement support for more than 15 arguments > in the compiler. > (which means that instead of error messages, it would compile, with the > idea as he described > in the mail). > > Marcus > > >

2 1

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2016