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

learning from errors....

by stepharo

I was looking at the LoadingMorph BTW: it would be good that QA does not refer to Komitter. And package it as a separate project. QA should not dependent on Komitter because we can remove Komitter. And it makes no sense! And it uses a state pattern, which is ok but there is not needed to create a new state all time. SmallCogInitialState >> nextState ^ SmallCogState2 new nextState ^ SmallCogState3 new We can have a state pattern without creating garbage all the time. Now I wonder who is using this LoadingMorph? Stef

Nov. 24, 2015

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

by Eliot Miranda

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. 24, 2015

Re: [Pharo-dev] Seaside REST on Pharo 50

by Franck Warlouzet

I don't have such an image anymore :( I guess Seaside and Seaside-Rest are enough (latest for both of them). Franck From: marcus.denker(a)inria.fr Date: Tue, 24 Nov 2015 13:45:14 -0300 To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] Seaside REST on Pharo 50 On 24 Nov 2015, at 12:43, Franck Warlouzet <franck.warlouzet(a)hotmail.fr> wrote:Hi, We are currently using seaside, magritte, reef etc to do a project at school. We also have to do a mobile app (written in Java :(), so we are doing a REST service to access the database from the mobile app. We are working on Pharo 50, and we noticed that Seaside-REST is not working anymore. For simple get, it is ok, for example : test <get> ^ 'foo' but if you want to have a complete path like that : test: aValue <get> <path: '/foo?value={aValue}'> ^ 'foo' You get a DNU RBVariableNode>>key during the route creating (Same on pharo 40 is working). Any idea why ? Can you provide an image where this happens? (just knowing what to load would take some effort elseâ¦) Marcus

Nov. 24, 2015

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

by Eliot Miranda

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

Nov. 24, 2015

Re: [Pharo-dev] problem using curl and wget in zero-conf -- explained

by Dale Henrichs

On 11/24/2015 04:30 AM, Ben Coman wrote: > On Tue, Nov 24, 2015 at 8:51 AM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> As I mentioned in the previous email, I sometimes have users report that >> they get the following error in their log file when installing >> pharo/GsDevKit-Home: >> >>> /home/travis/build/GsDevKit/GsDevKit_home/shared/pharo/pharo: line 11: >>> /home/travis/build/GsDevKit/GsDevKit_home/shared/pharo >> >> and I assumed that it was some sort of unreported error while downloading >> the pharo-vm (--silent used without --show-error for curl) ... fortunately >> I just started reliably getting this error on travis[1] and was able to >> track down the root cause of the bogus "file does not exist message" to the >> fact that the 32 bit libraries have not been installed[2]. >> >> It's true that the zero-conf script reports info that the 32-bit libraries >> were not installed, but the linux error message in this case is completely >> misleading ... it wasn't until I verified that the file did indeed exist[1] >> that I was able to investigate this further --- in my case I was expecting >> the 32-bit libraries to get installed in a later step and changes to the >> script structure resulted in the 32 bit library install being skipped ... >> >> At the end of the day, I think that error messages should not be suppressed >> by the zero-conf scripts, especially given the fact that the error message >> you get when a download does fail is pretty much the same as you'd get when >> you don't have the 32 bit libraries installed ... >> >> In my case, now that I understand that I cannot rely on a proper error error >> when 32-libraries have not been installed, I will have to see if I can come >> up with a way to provide a better error message for GsDevKit_home users .... >> >> Dale >> >> [1] https://travis-ci.org/GsDevKit/GsDevKit_home/jobs/92839591#L352 >> [2] >> http://askubuntu.com/questions/133389/no-such-file-or-directory-but-the-fil… >> >> >> On 11/23/2015 04:05 PM, Dale Henrichs wrote: >>> >>> >>> On 11/23/2015 03:39 PM, Esteban A. Maringolo wrote: >>>> 2015-11-23 20:25 GMT-03:00 Dale Henrichs >>>> <dale.henrichs(a)gemtalksystems.com>: >>>>> I've been using zero-conf scripts to download the pharo vm for a while >>>>> and >>>>> occasionally the download fails to install the vm in the pharo-vm >>>>> directory >>>>> .... silently ..... with no clue as to what happened. even worse the >>>>> exit >>>>> status is zero so the failure isn't noticed until much later on in my >>>>> install when an attempt is made to actually use the vm .... I do know >>>>> that >>>>> when I see these failures the pharo-vm does get created but is empty >>>>> ... >>>> +1. I've been bitten by this too. >>>> >>>> I would also like the option of seeing the progress of the download of >>>> the sources AND vm, because sometimes I want to know how the download >>>> is going on, speed, etc. >>>> >>>> Regards! >>>> >>>> -- >>>> Esteban >>>> >>> I agree with the progress, but when running as a batch job, you end up >>> with a ton of junk being dumped out into the log file ... getting rid of >>> junk from a log file is how I learned about the problem with --silent:) >>> >>> With regards to the issue I am having --- I have hit a point in my testing >>> (on travis) where I consistently get the: >>> >>>> /home/travis/build/GsDevKit/GsDevKit_home/shared/pharo/pharo: line 11: >>>> /home/travis/build/GsDevKit/GsDevKit_home/shared/pharo/pharo-vm/pharo: No >>>> such file or directory >>> >>> error message yet the following appears to work: >>> >>>> if [ "$OS" == "win" ]; then >>>> PHARO_VM=`find $VM_DIR -name ${VM_BINARY_NAME}.exe` >>>> elif [ "$OS" == "mac" ]; then >>>> PHARO_VM=`find $VM_DIR -name ${VM_BINARY_NAME}` >>>> elif [ "$OS" == "linux" ]; then >>>> PHARO_VM=`find $VM_DIR -name ${VM_BINARY_NAME_LINUX}` >>>> fi >>>> >>>> echo $PHARO_VM >>> >>> since `pharo-vm/pharo` is properly echoed even though the file does not >>> appear to exist? I'm digging deeper .... > I don't have a linux box to check this on, but how about something like... > > if [ `ldd $PHARO_VM 2>/dev/null | grep -c 'not found'` -ne 0 ]; then > echo "Missing library dependencies..." > ldd $PHARO_VM 2>/dev/null | grep 'not found' > echo "Maybe you need to..." > echo " $ sudo dpkg --add-architecture i386" > echo " $ sudo apt-get update" > echo "and for each $MISSING_LIBRARY..." > echo " $ sudo apt-get install $MISSING_LIBRARY:386" > exit 1 > fi > > cheers -ben I tend to agree with the original choice to not fail if the 32-bit libraries are not installed before downloading .... This kind of error exit _should_ be present in the pharo/poharo-ui scripts, so if one attempts to _run_ pharo without having the 32-bit libraries installed, you would get a meaningful error message .... Dale

Nov. 24, 2015

Re: [Pharo-dev] problem using curl and wget in zero-conf

by Dale Henrichs

Actually, I think that you should add the --show-error (with --silent) for curl and --no-verbose for wget, so that you get a more useful error message than "BOOM" ... you also should get a script exit from the curl/wget command as well which is exactly what _should_ happen... Dale On 11/24/2015 02:39 AM, Ben Coman wrote: > On Tue, Nov 24, 2015 at 7:25 AM, Dale Henrichs > <dale.henrichs(a)gemtalksystems.com> wrote: >> I've been using zero-conf scripts to download the pharo vm for a while and >> occasionally the download fails to install the vm in the pharo-vm directory >> .... silently ..... with no clue as to what happened. even worse the exit >> status is zero so the failure isn't noticed until much later on in my >> install when an attempt is made to actually use the vm > So to fail early after the download we should... > if [ ! -f "$VM_DIR/vm.zip" ] ; then > echo "BOOM!" > exit 1; > fi > > (?) cheers -ben > > >> .... I do know that when I see these failures the pharo-vm [directory] >> does get created but is empty ... >> >> I got another failure today and figured that I would dig into this on my end >> to see if I could understand what might be going on .... >> >> The section of the zero-conf script that is suspect is the following: >> >> mkdir $VM_DIR >> $DOWNLOAD_TO$VM_DIR/vm.zip $VM_URL >> >> >> After the $VM_DIR is created (which I know happens), the $DOWNLOAD_TO script >> is run. Recently, I learned that a side effect of using the --silent option >> for curl is that error messages are also suppressed and I see that for curl, >> the `--silent` option is being used: >> >> if [[ `which curl 2> /dev/null` ]]; then >> DOWNLOAD="curl --silent --location --compressed "; >> DOWNLOAD_TO="$DOWNLOAD --output "; >> elif [[ `which wget 2> /dev/null` ]]; then >> DOWNLOAD_TO="wget --quiet --output-document="; >> DOWNLOAD="$DOWNLOAD_TO-"; >> else >> echo "Please install curl or wget on your machine"; >> exit 1 >> fi >> >> >> For curl if you want to turn off the progress meter (a good thing) and >> continue to report errors, you need to use --show-error in conjunction with >> --silent (as described in the man page) >> >> I think the same thing applies to wget, --quiet turns off error messages and >> progress .... you probably should be using --no-verbose to continue to get >> error messages ... >> >> Dale >> >>

Nov. 24, 2015

Re: [Pharo-dev] News about FastTable

by Thierry Goubier

Hi Cyril, Le 24/11/2015 11:58, Ferlicot D. Cyril a Ã©crit : > Le 18/11/2015 10:53, Ferlicot D. Cyril a Ã©crit : >> Hi everyone! >> >> I just wanted to say that I added a first version of Tree in FastTable >> and I corrected some bugs. >> >> If someone want to try it and give some feedback you can see some >> examples on the latest Pharo 5 in FTExamples class. >> >> With Usman we also worked on the glamour version of FastTable begun by >> Esteban. >> You can see some examples of FastList, FastTable, FastOutlineList and >> FastTree in the GLMExamplesBrowser after executing this: >> >> (ConfigurationOfFastTable project version: #stable) load: #glamour >> >> Every feedback is welcome :) >> > > Hi, > > I took into account your feedback. > > I corrected the broken examples. > > I copied the Glamour package into glamour repository. I did not produced > a new configuration yet. > > Now the FastTree selection is updated when we collapse/extend an item. > The selection of collapsed item is not saved because with the current > implementation of FastTable that would be really complex. I think that > if someone want to have a widget with this feature that should be a > subclass of FTTreeDataSource and not a basic feature. Agreed. > And I did some small changes. > Selection probably doesn't work very well: I got a DNU in updateSelectionWithCollectBlock: (running exampleTree1, and trying the select in subtree then collapse) In Morphic-Widgets-FastTable-CyrilFerlicot.133 (changing collectAsSet: by collect: gives the correct behavior on the selection). Thierry

Nov. 24, 2015

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

by Marcus Denker

> On 24 Nov 2015, at 14:37, stepharo <stepharo(a)free.fr> wrote: > > flushCache The comment says it: "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.â Marcus

Nov. 24, 2015

About TBehavior

by stepharo

Hi I was reading the code of TBehavior and I'm puzzled. I do not get why - initialize does not call superclass: aClass methodDictionary: mDict format: fmt - what is this comment about not sending messages.... and doing it just after :( TBehavior >> initialize "moved here from the class side's #new" super initialize. self superclass: Object. "no longer sending any messages, some of them crash the VM" self methodDict: self emptyMethodDictionary. self setFormat: Object format. self traitComposition: nil. self users: IdentitySet new. TBehavior >> superclass: aClass methodDictionary: mDict format: fmt "Basic initialization of the receiver. Must only be sent to a new instance; else we would need Object flushCache." self superclass: aClass. self setFormat: fmt. self methodDict: mDict. self traitComposition: nil I really think that I would like to revisit the traits introduction in the kernel. Stef

Nov. 24, 2015

what is exactly flushCache?

by stepharo

Clement do you know what is flushCache and why we need to invoke it? Stef

Nov. 24, 2015