- Pharo-dev - lists.pharo.org

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

by Marcus Denker

> On 24 Nov 2015, at 17:00, 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. > This sentence used to be just in all primitives. it points to a long explanation to what is a primitive (in general) in method #whatIsAPrimitive. It does not want to explain this one primitive. There should be a sentence in addition. Marcus

Nov. 24, 2015

Re: [Pharo-dev] learning from errors....

by stepharo

What I think is that if we want to keep it we should make sure: - it does not create garbage all the time. - pckage it well (in a separate package) should be easy. - forms are cached (I checked and they are). Stef Le 24/11/15 20:58, Yuriy Tymchuk a Ã©crit : > I use it when you switch classes and methods. > > To avoid interrupting method browsing I set a loading morph and have > an async task with a priority lower than UI. When there is no UI > interaction the task gets critics and displays them. Usually the > âloadingâ morph is there only for a fraction of a second, but if you > are on a class with dozens of ivars and even more methods, then it can > take a longer time. > > I donât feel that the spinning cog is important there, but also I > think that it would be nice if we have some âin progressâ indicator. > Maybe there is already something in Bric though. > > Cheers. > Uko > >> On 24 Nov 2015, at 20:49, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> Hi Yiruy >> >> when do you use it because I could see it in action? >> We can package the animation out of komitter and fix this ugly state >> pattern (so naive :)). >> >> Stef >> >> Le 24/11/15 19:58, Yuriy Tymchuk a Ã©crit : >>> Good catch. >>> >>> At the time when I was developing it, the loading morph >>> implementation was such a magic for me, that I was super happy after >>> finishing it and forgot that I depend on Komitter. >>> >>> Is there any alternative for that? Otherwise I will simply remove >>> the spinning cog, I donât feel that this is super important. >>> >>> >>> Uko >>> >>>> On 24 Nov 2015, at 19:51, stepharo <stepharo(a)free.fr> wrote: >>>> >>>> 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! >>> >> >

Nov. 24, 2015

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

by stepharo

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. So I imagine that is Behavior flushCache flushing for the class in the class,selector pair. What would be a good place to add such comment? MethodDictionary. It sounds reasonable to me but tell me. 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 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> 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> 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 > <mailto:stepharo@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] learning from errors....

by Yuriy Tymchuk

I use it when you switch classes and methods. To avoid interrupting method browsing I set a loading morph and have an async task with a priority lower than UI. When there is no UI interaction the task gets critics and displays them. Usually the âloadingâ morph is there only for a fraction of a second, but if you are on a class with dozens of ivars and even more methods, then it can take a longer time. I donât feel that the spinning cog is important there, but also I think that it would be nice if we have some âin progressâ indicator. Maybe there is already something in Bric though. Cheers. Uko > On 24 Nov 2015, at 20:49, stepharo <stepharo(a)free.fr> wrote: > > Hi Yiruy > > when do you use it because I could see it in action? > We can package the animation out of komitter and fix this ugly state pattern (so naive :)). > > Stef > > Le 24/11/15 19:58, Yuriy Tymchuk a Ã©crit : >> Good catch. >> >> At the time when I was developing it, the loading morph implementation was such a magic for me, that I was super happy after finishing it and forgot that I depend on Komitter. >> >> Is there any alternative for that? Otherwise I will simply remove the spinning cog, I donât feel that this is super important. >> >> >> Uko >> >>> On 24 Nov 2015, at 19:51, stepharo < <mailto:stepharo@free.fr>stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: >>> >>> 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! >> >

Nov. 24, 2015

Re: [Pharo-dev] learning from errors....

by stepharo

Hi Yiruy when do you use it because I could see it in action? We can package the animation out of komitter and fix this ugly state pattern (so naive :)). Stef Le 24/11/15 19:58, Yuriy Tymchuk a Ã©crit : > Good catch. > > At the time when I was developing it, the loading morph implementation > was such a magic for me, that I was super happy after finishing it and > forgot that I depend on Komitter. > > Is there any alternative for that? Otherwise I will simply remove the > spinning cog, I donât feel that this is super important. > > > Uko > >> On 24 Nov 2015, at 19:51, stepharo <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> wrote: >> >> 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! >

Nov. 24, 2015

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

by ClÃ©ment Bera

Well Eliot answered before I did :-). Basically the VM caches expects the lookup to be stable: a given receiver class + selector should always answer the same lookup result. Installing or editing new methods invalidates this property and hence part of the cache needs to be flushed in when this happens (based on the method or the selector). 2015-11-24 19:10 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > > 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] learning from errors....

by Yuriy Tymchuk

Good catch. At the time when I was developing it, the loading morph implementation was such a magic for me, that I was super happy after finishing it and forgot that I depend on Komitter. Is there any alternative for that? Otherwise I will simply remove the spinning cog, I donât feel that this is super important. Uko > On 24 Nov 2015, at 19:51, stepharo <stepharo(a)free.fr> wrote: > > 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!

Nov. 24, 2015

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