November 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

by Thierry Goubier

Le 25/11/2015 18:27, Skip Lentz a Ã©crit : > Hi, > >> On Nov 24, 2015, at 5:30 PM, Skip Lentz <skip.lentz(a)inria.fr >> <mailto:skip.lentz@inria.fr>> wrote: >> >> I will set up a GitHub repository tomorrow. Right now itâs on >> SmalltalkHub, but I think itâs a good idea to put it on GitHub (if >> only for doing versioning with the tool itself). Then youâll be able >> to fork etc. >> >> Iâll report back in this thread. > > The migration to GitHub has been done, the repository is found here: > > https://github.com/Balletie/GitHub > > I wonder if the repository name is a problem... I saw other bindings use > this name as well though. > > I migrated all commits in chronological order, and switched to using > BaselineOf. > > Installation instructions are included in the README. This repository is > not metadata-less because otherwise I found no way to load it using > Metacello. > > Lastly, I have added several issues already (bugs, enhancements) to the > issue tracker. Feel free to add your own of course ;) Thanks, Thierry

Nov. 25, 2015

Re: [Pharo-dev] Cleanup of debug requests API

by Denis Kudriashov

2015-11-25 17:16 GMT+01:00 Andrei Chis <chisvasileandrei(a)gmail.com>: > Hi, > > In updating the debuggers from moose to the new API just one small issue > came up: > > - Process>>newDebugSessionNamed:startedAt: hardcodes DebugSession. However > we are using different debugging sessions. > > The class side method #sessionClass of a debugger returns the debugging > session's class. That could be used instead of DebugSession. > To provide fast fix we can rewrite process method with: Process>>newDebugSessionNamed: aString startedAt: aContext ^Smalltalk tools debugger sessionClass named: aString on: self startedAt: aContext Could you publish issue and slice? In my fixes I try to put single point for debugging. I removed some old methods and clean places where they was used. Session is actual debugger model. And I was think that it is better to always create debugger on it. Now I think that maybe debug session should be internal object for debugger. But it's seems strange. My main target is remote debugger. So I try to investigate all related stuff. What subclasses of DebugSession implement specifically? For what they needed? If we move to GTDebugger completely can we have only debug session class?

Nov. 25, 2015

Re: [Pharo-dev] Basic versioning of GitHub repositories from within Pharo

by Skip Lentz

Hi, > On Nov 24, 2015, at 5:30 PM, Skip Lentz <skip.lentz(a)inria.fr> wrote: > > I will set up a GitHub repository tomorrow. Right now itâs on SmalltalkHub, but I think itâs a good idea to put it on GitHub (if only for doing versioning with the tool itself). Then youâll be able to fork etc. > > Iâll report back in this thread. The migration to GitHub has been done, the repository is found here: https://github.com/Balletie/GitHub <https://github.com/Balletie/GitHub> I wonder if the repository name is a problem... I saw other bindings use this name as well though. I migrated all commits in chronological order, and switched to using BaselineOf. Installation instructions are included in the README. This repository is not metadata-less because otherwise I found no way to load it using Metacello. Lastly, I have added several issues already (bugs, enhancements) to the issue tracker. Feel free to add your own of course ;)

Nov. 25, 2015

Re: [Pharo-dev] what is exactly flushCache?

by Eliot Miranda

Hi Stef, > On Nov 24, 2015, at 12:00 PM, stepharo <stepharo(a)free.fr> wrote: > > Thanks for this great explanation and yes I know about this cache but I do not why > I was wondering that we did not need to update it from the image. > Now I would like to add such comment inside the system because I like self explanation. > > "See Object documentation whatIsAPrimitive." gets frustrates me. It's still appropriate to explain to newbies what primitives are and how they are invoked. Interesting to consider what the minimum knowledge programmers have when first using the system. Do they know, for example, that methods contain bytecode for a stack machine, or that underneath the system is a virtual machine containing a bytecode execution engine, a set of primitives and (a) garbage collector(s)? > So I imagine that is Behavior flushCache flushing for the class in the class,selector pair. Again because of inheritance the VM can't just flush entries for a specific class, so the VM responds to Behavior>>flushCache flushes the entire cache. > What would be a good place to add such comment? MethodDictionary. It sounds reasonable to me but tell me. If the comments in the various flushCache implementations are correct and reference each other then I think that's enough. > TBehavior >> flushCache > "Tell the interpreter to remove the contents of its method lookup cache, if it has > one. Essential. See Object documentation whatIsAPrimitive." > > <primitive: 89> > self primitiveFailed I would rewrite this to say "Tell the virtual machine to remove the contents of its method lookup caches, if it has any. This must be done when the system modifies the class hierarchy so that message lookups reflect the revised organization. c.f. Symbol>>flushCache & CompiledMethod>>flushCache. Essential. See Object documentation whatIsAPrimitive." > Symbol >> flushCache > "Tell the interpreter to remove all entries with this symbol as a selector from its method lookup cache, if it has one. This primitive must be called whenever a method is redefined or removed. > NOTE: Only one of the two selective flush methods (Symbol or CompiledMethod) needs to be used." > > <primitive: 119> I would rewrite this to say "Tell the virtual machine to remove all entries with this symbol as a selector from its method lookup caches, if it has any. This must be done whenever a method is added, redefined or removed, so that message lookups reflect the revised organization. c.f. Behavior>>flushCache & CompiledMethod>>flushCache. Essential. See Object documentation whatIsAPrimitive." > CompiledMethod >> flushCache > "Tell the interpreter to remove all references to this method from its method lookup cache, if it has one. This primitive must be called whenever a method is redefined or removed. > NOTE: Only one of two selective flush methods (Symbol or CompiledMethod) needs to be used." > > <primitive: 116> I would rewrite this to say "Tell the virtual machine to remove all references to this method from its method lookup caches, and to discard any optimized version of the method, if it has any of these. This must be done whenever a method is modified in place, such as modifying its literals or machine code, to reflect the revised code. c.f. Behavior>>flushCache & Symbol>>flushCache. Essential. See Object documentation whatIsAPrimitive." > Le 24/11/15 19:10, Eliot Miranda a Ã©crit : >> Hi Stephane, >> >> the VM caches method lookups in a lookup cache from class,selector pairs to method,primitive pairs, where primitive may be null. This is called the first-level method lookup cache. The JIT VM caches message lookups in machine code, so that a particular piece of machine code exists in a state that invokes a method for a specific class very fast by embedding the class reference in a register load and the target method in a call instruction, and having the target method verify this "cache probe" (this is an "in-line cache). The JIT also caches the translation of a byte coded method to machine code, by hiding a reference to a machine code method in a byte coded method. >> >> These caches can be invalidated in several circumstances: >> >> 1a. if one adds or removes a method from a class's method dictionary it may change the correct results of a lookup not merely of the class whose dictionary was updated but also subclasses of the class. >> 1b. if one replaces a method in a method dictionary this changes the target method for a lookup of the selector for the class and subclasses >> >> 2. if one wants to rewrite the byte code or literals of a method, for example because a Slot definition has changed, then if the method has been compiled to machine code, the machine code must be discarded before the new code may be executed >> >> 1a & 1b are done via Symbol>>flushCache. In response the normal VM flushes its first-level method lookup cache, and the JIT also scans all of machine code looking for inline caches with that selector, and voiding them, reverting each send site for that selector to the "unlinked" state. >> >> There used to be confusion in Squeak, which Pharo inherited, that using CompiledMethod>>flushCache was somehow the right way to void caches when updating method dictionaries, flushing the old method in the dictionary, if any, and the new method. It isn't, precisely because adding or removing methods affects the visibility of inherited methods with the same selector. So MethodDictionary code should use Symbol>>flushCache, and only once, on each update of a method dictionary. As a result, the VM will ensure that the necessary send caches are flushed for that selector. >> >> 2. is done via CompiledMethod>>flushCache. In response the VM searches the first-level method lookup cache and removes all entries whose target is the method. In addition the JIT discards the machine code for the method, and searches for all send sites with that method's machine code as the target and voids them, reverting them to the unlinked state. >> >> The VM must be told to flush the cached state for a compiled method via CompiledMethod>>flushCache and will /try/ and void the state for that method. But it can't always deal with existing activations of that method, because if there are activations running the machine code, that machine code can't merely be thrown away, and can't be replaced because its length may change, depending on literals or byte codes. So this kind of byte coded method manipulation needs to be done with case and some understanding of the total system state. >> >> HTH >> >> >>> On Tue, Nov 24, 2015 at 9:37 AM, stepharo <stepharo(a)free.fr> wrote: >>> Clement >>> >>> do you know what is flushCache and why we need to invoke it? >>> >>> Stef >> >> _,,,^..^,,,_ >> best, Eliot _,,,^..^,,,_ (phone)

Nov. 25, 2015

Re: [Pharo-dev] vm crash in SmalltalkImage>garbageCollect

by Andrei Chis

Hi Eliot, Thanks for explaining this. For now I just removed the explicit #garbageCollect that we were doing in the test that was causing the error and I cannot reproduce it any more. We'll see if this comes back again. Cheers, Andrei On Tue, Nov 24, 2015 at 7:34 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Mon, Nov 23, 2015 at 4:57 PM, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> Hi Eliot, >> >> Is an assert vm the same as a vm compiled with debugging support? >> > > VMMaker.oscog generates VM sources designed to be compiled in three > different ways, Debug, Assert and Production. Debug is designed to enable > asserts to check invariants and be compiled with no optimization for > maximum debuggability. Assert is designed to enable asserts to check > invariants and be compiled with limited optimization for faster assert > checking. Production has asserts disabled (actually compiled-out) and be > compiled with aggressive optimization, so it has limited debuggability (it > should still contain debugging symbols). > > So Assert and Debug are not quite the same and certainly if you're hunting > for storage leaks an Assert VM will run much faster than a Debug VM. If > you have a look at the Cog svn sources you'll find that the build scripts > build all three kinds of VMs for all platforms. > > > > Also can you point me to any documentation about the leak checker. >> > > It's not well documented because it may change over time, but the -help > flag on the VM should include this: > > -leakcheck num check for leaks in the heap > > and the meaning of num is a set of flags: > > setCheckForLeaks: integerFlags > " 0 = do nothing. > 1 = check for leaks on fullGC (GCModeFull). > 2 = check for leaks on scavenger (GCModeNewSpace). > 4 = check for leaks on incremental (GCModeIncremental) > 8 = check for leaks on become > 16 = check for leaks on image segments" > checkForLeaks := integerFlags > > So once you have your assert VM try running your test case using > > myvm -leakcheck 5 myimage.image > > on the command line. You'll want to use a debugger to put breakpoints in > the leak checker and you may need to learn about the VM's debug routines to > try and figure out the cause of the leak once the leak checker finds it. > >> Cheers, >> Andrei >> >> On Nov 24, 2015 1:45 AM, "Eliot Miranda" <eliot.miranda(a)gmail.com> wrote: >> > >> > Hi Andrei, >> > >> > On Mon, Nov 23, 2015 at 7:59 AM, Andrei Chis < >> chisvasileandrei(a)gmail.com> wrote: >> >> >> >> Hi, >> >> >> >> With both the latest and stable vm I have an use case in which the vm >> crashed in SmalltalkImage>>garbageCollect. >> >> >> >> To set up an image that exhibits the failure , execute this with the >> latest pharo version: >> >> >> >> /pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. 'Pharo'. >> 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. { >> 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer >> new smalltalkhubUser: spec second project: spec third; package: spec first; >> load ]." >> >> >> >> ./pharo Pharo.image config >> http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main >> ConfigurationOfGToolkitCore --install=3.2 >> >> >> >> Then attempting to run the following code triggers the failure: >> >> >> >> ./pharo Pharo.image eval --save "TestRunner open model >> packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: >> 'GTInspectorExamplesTest'; runAll" >> >> >> >> Based on the trace below the failure happens when the >> test GTInspectorExamplesTest calls 'Smalltalk>>garbageCollect' in the setUp >> method. >> >> >> >> That call can be removed, however, in other runs the failure happens >> in other methods calling Smalltalk>>garbageCollect. >> >> >> >> Is it possible that this is a bug with the image (some broken object) >> or is it a vm bug? >> > >> > >> > The way to test this is to build an assert VM and then use the leak >> checker. The leak checker will allow you to narrow down the cause. If the >> leak checker shows no corruption then its definitely a GC bug. If there >> leak checker does show corruption before GC then one still has to find out >> what caused the heap corruption, but you can use the leak checker to narrow >> the search. >> > >> > HTH >> > Eliot >> > >> >> Cheers, >> >> >> >> Andrei >> >> >> >> >> >> >> >> andrei$ ./pharo Pharo.image eval --save "{ { 'ConfigurationOfRubric'. >> 'Pharo'. 'Rubric' }. { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. >> { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTEventRecorder'. 'Moose'. 'GToolkit' }. { >> 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. } do: [ :spec | Gofer >> new smalltalkhubUser: spec second project: spec third; package: spec first; >> load ]." >> >> >> >> andrei$ ./pharo Pharo.image config >> http://www.smalltalkhub.com/mc/Pharo/Pharo50Inbox/main >> ConfigurationOfGToolkitCore --install=3.2 >> >> >> >> andrei$ ./pharo Pharo.image eval --save "TestRunner open model >> packageSearchUpdate: 'gt-tests-inspector'; classSearchUpdate: >> 'GTInspectorExamplesTest'; runAll" >> >> >> >> >> >> Segmentation fault Mon Nov 23 16:48:36 2015 >> >> >> >> >> >> >> >> https://github.com/pharo-project/pharo-vm.git Commit: >> 28d077d8df494ce050ca42c97c892471e8b8740c Date: 2015-10-16 12:02:43 +0200 >> By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #15016 >> >> >> >> >> >> C stack backtrace: >> >> >> >> 0 Pharo 0x0004cacf reportStackState + >> 159 >> >> >> >> >> >> >> >> Smalltalk stack dump: >> >> >> >> 0xbffbf1a0 M SmalltalkImage>garbageCollect 0x1fd49e30: a(n) >> SmalltalkImage >> >> >> >> 0xbffbf1c0 I GTInspectorExamplesTest>setUp 0x2126bc80: a(n) >> GTInspectorExamplesTest >> >> >> >> 0x2126cb90 is not a context >> >> >> >> >> >> Most recent primitives >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> basicNew >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> shallowCopy >> >> >> >> new >> >> >> >> new: >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> replaceFrom:to:with:startingAt: >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> replaceFrom:to:with:startingAt: >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> perform:with: >> >> >> >> perform:with: >> >> >> >> perform: >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> perform:with: >> >> >> >> perform:with: >> >> >> >> perform: >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> new >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> new: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> shallowCopy >> >> >> >> shallowCopy >> >> >> >> @ >> >> >> >> @ >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> new: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> at:put: >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> @ >> >> >> >> basicNew >> >> >> >> @ >> >> >> >> @ >> >> >> >> perform: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> shallowCopy >> >> >> >> shallowCopy >> >> >> >> primUTCMicrosecondsClock >> >> >> >> // >> >> >> >> basicNew >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> value >> >> >> >> valueNoContextSwitch >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> replaceFrom:to:with:startingAt: >> >> >> >> primitiveGarbageCollect >> >> >> >> **IncrementalGC** >> >> >> >> **FullGC** >> >> >> >> garbageCollectMost >> >> >> >> **IncrementalGC** >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> someInstance >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> someInstance >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> someInstance >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> replaceFrom:to:with:startingAt: >> >> >> >> primitiveGarbageCollect >> >> >> >> **IncrementalGC** >> >> >> >> **FullGC** >> >> >> >> garbageCollectMost >> >> >> >> **IncrementalGC** >> >> >> >> wait >> >> >> >> shallowCopy >> >> >> >> shallowCopy >> >> >> >> signal >> >> >> >> wait >> >> >> >> shallowCopy >> >> >> >> shallowCopy >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> signal >> >> >> >> wait >> >> >> >> shallowCopy >> >> >> >> shallowCopy >> >> >> >> at:put: >> >> >> >> at:put: >> >> >> >> signal >> >> >> >> new: >> >> >> >> basicNew >> >> >> >> new: >> >> >> >> replaceFrom:to:with:startingAt: >> >> >> >> primitiveGarbageCollect >> >> >> >> **IncrementalGC** >> >> >> >> **FullGC** >> >> >> >> >> >> (Segmentation fault) >> >> >> >> ./pharo: line 11: 5224 Abort trap: 6 >> "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" --headless "$@" >> > >> > >> > >> > >> > -- >> > _,,,^..^,,,_ >> > best, Eliot >> > > > > -- > _,,,^..^,,,_ > best, Eliot >

Nov. 25, 2015

Re: [Pharo-dev] Is code pane should show secondary selection on any characters like spaces and tabs?

by Marcus Denker

Yes, I think that would be good. The space selection is strangeâ¦. > On 25 Nov 2015, at 13:09, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > When you select single space on code pane all spaces in code become selected. To me it is look very weird. > > If I'm not alone on this feeling we can integrate issue 16962 <https://pharo.fogbugz.com/f/cases/16962/Code-pane-should-not-show-all-space…> > > For more details current behavior is: > If you select "self", all "self"s in the code pane are selected with "secondary selection color" > If you select "." all dots are selected. > If you select a space-char all spacess are selected > If you select a tab-char all tabs are selected ... > > With my fix you will not see secondary selection on any separators (space ,tab). > It was my first impression when I start to navigate/select text by command left/right. And spaces selection during this process looks to me very bad.

Nov. 25, 2015

Re: [Pharo-dev] Thread pre-emption semantics

by Guillermo Polito

Well, there are also some primitive calls that can suspend the current process: * When a process resumes a process of a higher priority than himself * When a new process is created with a higher priority than the current process (a subcase of the one above) * When a process explicitly calls *Processor yield* > On 25 nov 2015, at 5:29 p.m., Ben Coman <btc(a)openinworld.com> wrote: > > I have a general idea of thread pre-emption semantics, but just trying > to pin it down for some documentation. I found reference that thread > context switches can only happen on: > * backward branches > * activation of non-primitive sends > > but I believe also that context switches can't occur between inlined > message send like ifNil:ifNotNil: ? > Are there any other I missed? > > cheers -ben >

Nov. 25, 2015

Thread pre-emption semantics

by Ben Coman

I have a general idea of thread pre-emption semantics, but just trying to pin it down for some documentation. I found reference that thread context switches can only happen on: * backward branches * activation of non-primitive sends but I believe also that context switches can't occur between inlined message send like ifNil:ifNotNil: ? Are there any other I missed? cheers -ben

Nov. 25, 2015

Re: [Pharo-dev] Cleanup of debug requests API

by Andrei Chis

Hi, In updating the debuggers from moose to the new API just one small issue came up: - Process>>newDebugSessionNamed:startedAt: hardcodes DebugSession. However we are using different debugging sessions. The class side method #sessionClass of a debugger returns the debugging session's class. That could be used instead of DebugSession. Cheers, Andrei

Nov. 25, 2015

Is code pane should show secondary selection on any characters like spaces and tabs?

by Denis Kudriashov

When you select single space on code pane all spaces in code become selected. To me it is look very weird. If I'm not alone on this feeling we can integrate issue 16962 <https://pharo.fogbugz.com/f/cases/16962/Code-pane-should-not-show-all-space…> For more details current behavior is: If you select "self", all "self"s in the code pane are selected with "secondary selection color" If you select "." all dots are selected. If you select a space-char all spacess are selected If you select a tab-char all tabs are selected ... With my fix you will not see secondary selection on any separators (space ,tab). It was my first impression when I start to navigate/select text by command left/right. And spaces selection during this process looks to me very bad.

Nov. 25, 2015