January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Syntax Highlighting error (RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance)

by Marcus Denker

Hello, This is now integrated. > On 05 Jan 2016, at 16:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > yes, > > this is fixed by > > https://pharo.fogbugz.com/f/cases/17276/Semantic-Analysis-needs-refactoring > > I am now back from holidays and will review/intergrate this soon. > > >> On 05 Jan 2016, at 16:15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> I am seeing the following very annoying error in 50511 spur. >> >> Open a Playground, >> type [ (both open en close are inserted, with the cursor in-between), >> type : (to start a block arg), >> boom: >> >> RBParseErrorNode(Object)>>doesNotUnderstand: #isInstance >> OCASTClosureAnalyzer>>changeVariableClass: >> OCASTClosureAnalyzer>>visitArgumentNode: >> [ :each | self visitArgumentNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: >> OrderedCollection>>do: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitArgumentNodes: >> OCASTClosureAnalyzer>>visitBlockNode: >> RBBlockNode>>acceptVisitor: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >> [ :each | self visitNode: each ] in OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: >> OrderedCollection>>do: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitSequenceNode: >> RBSequenceNode>>acceptVisitor: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >> OCASTClosureAnalyzer>>visitMethodNode: >> RBMethodNode>>acceptVisitor: >> OCASTClosureAnalyzer(RBProgramNodeVisitor)>>visitNode: >> OCASTSemanticAnalyzer>>analyze: >> RBMethodNode>>doSemanticAnalysis >> RBBlockNode(RBProgramNode)>>doSemanticAnalysis >> RubSHTextStylerST80(SHRBTextStyler)>>privateStyle: >> [ self privateStyle: text. >> view ifNotNil: [ view stylerStyledInBackground: text ] ] in [ backgroundProcess := [ self privateStyle: text. >> view ifNotNil: [ view stylerStyledInBackground: text ] ] >> forkAt: Processor userBackgroundPriority ] in RubSHTextStylerST80(SHTextStyler)>>styleInBackgroundProcess: >> [ self value. >> Processor terminateActive ] in BlockClosure>>newProcess >> >> Has this already been reported ? >> >> It makes the image almost unusable... >> >> Sven >> >> >

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

Ugh, there's a bug with the Processor activeProcess suspendingList, I only checked in the case where it *should* signal. Take it as an inspiration :) Cheers, Henry > On 08 Jan 2016, at 2:40 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Here's an alternative implementation, which, instead of checking for the new method name, hooks into the existing unwind machinery to execute the waitIfCurtailed: argument. > Which removes the special case from Process >> #terminate, but at the added cost that in-progress unwinds are executed as if the (suspended) terminating thread they started executing on, is still the active process. (Which, arguably, should be done anyways) > > Cheers, > Henry > > <SignalUsingUnwindMachinery.cs> > > > "This runs on UI thread, pri 40" > waiter := Semaphore new. > waiter2 := Semaphore new. > lock := Semaphore forMutualExclusion. > > proc := [lock critical2: [ Transcript crShow: '1 start'. > waiter wait. > Transcript crShow: '1 done'.]] newProcess. > proc priority: 70. > proc resume. > > proc2 := [lock critical2: [ Transcript crShow: '2 start'. > waiter2 wait. > Transcript crShow: '2 done'. ]] newProcess. > proc2 priority: 15. > proc2 resume. > > "Yield for proc2 so it gets to waiting on lock" > 1 second wait. > "Signal waiter and yield, causing proc1 to run, and release the lock. lock will then remove proc2 from waiting list" > waiter signal. > Processor yield. > "We have a higher pri than proc2, and will resume execution here before proc2 has chance to run" > proc2 terminate. > "proc2 has been curtailed before running, thus ifCurtailed: guard is still on stack and will be run as part of termination." > (lock instVarNamed: 'excessSignals') 1 >> On 07 Jan 2016, at 11:09 , Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> Ok. slice 17340 <https://pharo.fogbugz.com/f/cases/17340/Semaphore-critical-should-handle-in…> in inbox. It is only touches current #critical: implementation. It is not about deprecation wrong semaphore usage >> >> 2016-01-07 9:55 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >> >> 2016-01-07 0:15 GMT+01:00 Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>>: >> >> I'm not qualified to judge, but is sounds okay. I have an alternative >> proposal to consider that hopefully might remove Semaphore handling >> completely from Process>>terminate. >> >> What if we have a wait primitive that instead of returning itself >> (i.e. a Semaphore), it always returns true. Then if the process is >> terminated while the primitive is waiting, before it consumes a >> signal, the assignment to signalConsumed never occurs. Then we >> have... >> >> critical: mutuallyExcludedBlock >> signalConsumed := false. >> [ >> signalConsumed := self primWaitSucceeded. >> blockValue := mutuallyExcludedBlock value >> ] ensure: [ signalConsumed ifTrue: [self signal] ]. >> ^blockValue >> >> It *feels* more atomic. Someone knowledgeable with the vm would need >> to advise whether after the primitive wakes up and consumes a signal, >> the assignment into signalConsumed can be guaranteed to occur before >> the process gets a chance to terminate, even if the primitive needs to >> directly poke the value into signalConsumed. >> >> To me it is better too. But it requires changes in VM primitive which I'm can't provide. >> So I will implement my idea. Do you ok with the name #waitIfInterrupted? >> >

Jan. 8, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50518 Home: https://github.com/pharo-project/pharo-core

Jan. 8, 2016

[pharo-project/pharo-core] 54e47e: 50518

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 54e47eec2c5cdc081b4a8e94428e656ca2489211 https://github.com/pharo-project/pharo-core/commit/54e47eec2c5cdc081b4a8e94… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-08 (Fri, 08 Jan 2016) Changed paths: A AST-Core.package/RBArgumentNode.class/instance/converting/adaptToSemanticNode.st A AST-Core.package/RBParseErrorNode.class/instance/converting/adaptToSemanticNode.st A AST-Core.package/RBVariableNode.class/instance/converting/adaptToSemanticNode.st R OpalCompiler-Core.package/OCASTClosureAnalyzer.class/instance/variables/changeVariableClass_.st M OpalCompiler-Core.package/OCASTClosureAnalyzer.class/instance/visiting/visitArgumentNode_.st M OpalCompiler-Core.package/OCASTClosureAnalyzer.class/instance/visiting/visitVariableNode_.st A OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/variables/declareArgumentNode_.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/variables/declareVariableNode_.st A OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/variables/declareVariableNode_as_.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/visitor/visitBlockNode_.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/visitor/visitInlinedBlockNode_.st M OpalCompiler-Core.package/OCASTSemanticAnalyzer.class/instance/visitor/visitMethodNode_.st R OpalCompiler-Core.package/OCAbstractLocalVariable.class/instance/read%2Fwrite usage/isArg.st M OpalCompiler-Core.package/OCAbstractLocalVariable.class/instance/read%2Fwrite usage/isUninitialized.st R OpalCompiler-Core.package/OCAbstractLocalVariable.class/instance/read%2Fwrite usage/markArg.st M OpalCompiler-Core.package/OCAbstractMethodScope.class/instance/initialization/initialize.st M OpalCompiler-Core.package/OCAbstractMethodScope.class/instance/temp vars/addTemp_.st A OpalCompiler-Core.package/OCAbstractMethodScope.class/instance/temp vars/addTemp_withName_.st A OpalCompiler-Core.package/OCAbstractVariable.class/class/accessing/semanticNodeClass.st R OpalCompiler-Core.package/OCAbstractVariable.class/instance/accessing/asString.st R OpalCompiler-Core.package/OCAbstractVariable.class/instance/accessing/isArg.st A OpalCompiler-Core.package/OCAbstractVariable.class/instance/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCAbstractVariable.class/instance/converting/asString.st M OpalCompiler-Core.package/OCAbstractVariable.class/instance/read%2Fwrite usage/isRead.st A OpalCompiler-Core.package/OCAbstractVariable.class/instance/testing/isArg.st A OpalCompiler-Core.package/OCArgumentVariable.class/README.md A OpalCompiler-Core.package/OCArgumentVariable.class/class/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCArgumentVariable.class/definition.st A OpalCompiler-Core.package/OCArgumentVariable.class/instance/testing/isArg.st A OpalCompiler-Core.package/OCArgumentVariable.class/instance/testing/isUninitialized.st A OpalCompiler-Core.package/OCArgumentVariable.class/instance/testing/isWritable.st M OpalCompiler-Core.package/OCInstanceScope.class/instance/initialization/initialize.st A OpalCompiler-Core.package/OCLiteralVariable.class/class/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCSelfVariable.class/README.md A OpalCompiler-Core.package/OCSelfVariable.class/class/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCSelfVariable.class/definition.st A OpalCompiler-Core.package/OCSelfVariable.class/instance/initialization/initialize.st A OpalCompiler-Core.package/OCSelfVariable.class/instance/testing/isSelf.st A OpalCompiler-Core.package/OCSlotVariable.class/class/accessing/semanticNodeClass.st M OpalCompiler-Core.package/OCSpecialVariable.class/instance/emitting/emitValue_.st R OpalCompiler-Core.package/OCSpecialVariable.class/instance/testing/isContext.st R OpalCompiler-Core.package/OCSpecialVariable.class/instance/testing/isSelf.st R OpalCompiler-Core.package/OCSpecialVariable.class/instance/testing/isSuper.st A OpalCompiler-Core.package/OCSpecialVariable.class/instance/testing/isThisContext.st A OpalCompiler-Core.package/OCSuperVariable.class/README.md A OpalCompiler-Core.package/OCSuperVariable.class/class/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCSuperVariable.class/definition.st A OpalCompiler-Core.package/OCSuperVariable.class/instance/initialization/initialize.st A OpalCompiler-Core.package/OCSuperVariable.class/instance/testing/isSuper.st A OpalCompiler-Core.package/OCTempVariable.class/class/accessing/semanticNodeClass.st R OpalCompiler-Core.package/OCTempVariable.class/instance/testing/isWritable.st A OpalCompiler-Core.package/OCThisContextVariable.class/README.md A OpalCompiler-Core.package/OCThisContextVariable.class/class/accessing/semanticNodeClass.st A OpalCompiler-Core.package/OCThisContextVariable.class/definition.st A OpalCompiler-Core.package/OCThisContextVariable.class/instance/emitting/emitValue_.st A OpalCompiler-Core.package/OCThisContextVariable.class/instance/initialization/initialize.st A OpalCompiler-Core.package/OCThisContextVariable.class/instance/testing/isThisContext.st A OpalCompiler-Core.package/OCUndeclaredVariable.class/class/accessing/semanticNodeClass.st M OpalCompiler-Tests.package/OCASTCheckerTest.class/instance/testing - variables/testExampleThisContext.st M Reflectivity.package/RFSemanticAnalyzer.class/instance/visiting/visitMethodNode_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50517.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50518.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50517.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50518.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50518 17276 Semantic Analysis needs refactoring https://pharo.fogbugz.com/f/cases/17276 http://files.pharo.org/image/50/50518.zip

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

Here's an alternative implementation, which, instead of checking for the new method name, hooks into the existing unwind machinery to execute the waitIfCurtailed: argument. Which removes the special case from Process >> #terminate, but at the added cost that in-progress unwinds are executed as if the (suspended) terminating thread they started executing on, is still the active process. (Which, arguably, should be done anyways) Cheers, Henry "This runs on UI thread, pri 40" waiter := Semaphore new. waiter2 := Semaphore new. lock := Semaphore forMutualExclusion. proc := [lock critical2: [ Transcript crShow: '1 start'. waiter wait. Transcript crShow: '1 done'.]] newProcess. proc priority: 70. proc resume. proc2 := [lock critical2: [ Transcript crShow: '2 start'. waiter2 wait. Transcript crShow: '2 done'. ]] newProcess. proc2 priority: 15. proc2 resume. "Yield for proc2 so it gets to waiting on lock" 1 second wait. "Signal waiter and yield, causing proc1 to run, and release the lock. lock will then remove proc2 from waiting list" waiter signal. Processor yield. "We have a higher pri than proc2, and will resume execution here before proc2 has chance to run" proc2 terminate. "proc2 has been curtailed before running, thus ifCurtailed: guard is still on stack and will be run as part of termination." (lock instVarNamed: 'excessSignals') 1 > On 07 Jan 2016, at 11:09 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Ok. slice 17340 <https://pharo.fogbugz.com/f/cases/17340/Semaphore-critical-should-handle-in…> in inbox. It is only touches current #critical: implementation. It is not about deprecation wrong semaphore usage > > 2016-01-07 9:55 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > > 2016-01-07 0:15 GMT+01:00 Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>>: > > I'm not qualified to judge, but is sounds okay. I have an alternative > proposal to consider that hopefully might remove Semaphore handling > completely from Process>>terminate. > > What if we have a wait primitive that instead of returning itself > (i.e. a Semaphore), it always returns true. Then if the process is > terminated while the primitive is waiting, before it consumes a > signal, the assignment to signalConsumed never occurs. Then we > have... > > critical: mutuallyExcludedBlock > signalConsumed := false. > [ > signalConsumed := self primWaitSucceeded. > blockValue := mutuallyExcludedBlock value > ] ensure: [ signalConsumed ifTrue: [self signal] ]. > ^blockValue > > It *feels* more atomic. Someone knowledgeable with the vm would need > to advise whether after the primitive wakes up and consumes a signal, > the assignment into signalConsumed can be guaranteed to occur before > the process gets a chance to terminate, even if the primitive needs to > directly poke the value into signalConsumed. > > To me it is better too. But it requires changes in VM primitive which I'm can't provide. > So I will implement my idea. Do you ok with the name #waitIfInterrupted? >

Jan. 8, 2016

Re: [Pharo-dev] [Pharo-users] [Moose-dev] Re: gtdebugger in pharo 5.0

by Andrei Chis

On Fri, Jan 8, 2016 at 2:23 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > is there any documentation about this ? or i just look at the relevant > classes ? > Not really. Now you'll need to look in UITheme>>styleContext:from:, but I'll refactor that method shortly. > On Fri, Jan 8, 2016 at 3:20 PM Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >>> does the GTDebugger respect the pharo themes support or is it like >>> GTSpotter ? >>> >> >> It behaves just as GTInspector regrading the theme. Just if you are >> using a custom theme and want to have the coloring of the stack enabled you >> need to provide the appropriate colors in your theme (styleContext:from:) >> >> Cheers, >> Andrei >> >> >> >>> >>> On Fri, Jan 8, 2016 at 1:08 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>>> Hi, >>>> >>>> We are about to integrate in Pharo a new member of the Glamorous >>>> Toolkit: the GTDebugger. As this is a significant change that might affect >>>> your workflow, here is some background information to help you deal >>>> with the change. >>>> >>>> First, you should know that the change is not irreversible and it is >>>> easily possible to disabled the new debugger through a setting. However, >>>> please do take the time to provide us feedback if something does not work >>>> out for you. We want to know what can be improved and we try to react as >>>> fast as we can. >>>> >>>> A practical change comes from the fact that the variables are >>>> manipulated through a GTInspector, which makes it cheaper to maintain in >>>> the longer run. >>>> >>>> While the first thing that will capture the attention is the default >>>> generic interface, the real power comes from the moldable nature of the >>>> debugger. Like all other GT tools, GTDebugger is also moldable by design. >>>> This means that we can construct custom debuggers for specific libraries at >>>> small costs (often measured in a couple of hundred lines of code). >>>> >>>> For example, the core configuration includes also the SUnit and the >>>> bytecode debugger. These are around 150 lines of code. Here is how the >>>> bytecode debugger looks like: >>>> >>>> >>>> >>>> You can find more information in an introductory overview blog post >>>> that also includes some links for further reading: >>>> >>>> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ >>>> >>>> Please let us know what you think. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "What is more important: To be happy, or to make happy?" >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> Moose-dev(a)list.inf.unibe.ch >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >>> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >

Jan. 8, 2016

Re: [Pharo-dev] What is the current status of flow (flow-stack)?

by Craig Latta

Hoi Erik-- > SqueakJS seems a 'heavy' solution since I probably would like to keep > the front-end relatively thin (and not use the Morphic UI). You can also use the MVC UI, or use no Smalltalk graphics at all and just manipulate the DOM etc. via the JavaScript bridge. -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Jan. 8, 2016

Re: [Pharo-dev] [Moose-dev] Re: gtdebugger in pharo 5.0

by Dimitris Chloupis

is there any documentation about this ? or i just look at the relevant classes ? On Fri, Jan 8, 2016 at 3:20 PM Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > >> does the GTDebugger respect the pharo themes support or is it like >> GTSpotter ? >> > > It behaves just as GTInspector regrading the theme. Just if you are using > a custom theme and want to have the coloring of the stack enabled you need > to provide the appropriate colors in your theme (styleContext:from:) > > Cheers, > Andrei > > > >> >> On Fri, Jan 8, 2016 at 1:08 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> We are about to integrate in Pharo a new member of the Glamorous >>> Toolkit: the GTDebugger. As this is a significant change that might affect >>> your workflow, here is some background information to help you deal >>> with the change. >>> >>> First, you should know that the change is not irreversible and it is >>> easily possible to disabled the new debugger through a setting. However, >>> please do take the time to provide us feedback if something does not work >>> out for you. We want to know what can be improved and we try to react as >>> fast as we can. >>> >>> A practical change comes from the fact that the variables are >>> manipulated through a GTInspector, which makes it cheaper to maintain in >>> the longer run. >>> >>> While the first thing that will capture the attention is the default >>> generic interface, the real power comes from the moldable nature of the >>> debugger. Like all other GT tools, GTDebugger is also moldable by design. >>> This means that we can construct custom debuggers for specific libraries at >>> small costs (often measured in a couple of hundred lines of code). >>> >>> For example, the core configuration includes also the SUnit and the >>> bytecode debugger. These are around 150 lines of code. Here is how the >>> bytecode debugger looks like: >>> >>> >>> >>> You can find more information in an introductory overview blog post that >>> also includes some links for further reading: >>> >>> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ >>> >>> Please let us know what you think. >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "What is more important: To be happy, or to make happy?" >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)list.inf.unibe.ch >>> https://www.list.inf.unibe.ch/listinfo/moose-dev >>> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Jan. 8, 2016

Re: [Pharo-dev] [Moose-dev] Re: gtdebugger in pharo 5.0

by Andrei Chis

On Fri, Jan 8, 2016 at 2:09 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > does the GTDebugger respect the pharo themes support or is it like > GTSpotter ? > It behaves just as GTInspector regrading the theme. Just if you are using a custom theme and want to have the coloring of the stack enabled you need to provide the appropriate colors in your theme (styleContext:from:) Cheers, Andrei > > On Fri, Jan 8, 2016 at 1:08 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Hi, >> >> We are about to integrate in Pharo a new member of the Glamorous Toolkit: >> the GTDebugger. As this is a significant change that might affect your >> workflow, here is some background information to help you deal with the >> change. >> >> First, you should know that the change is not irreversible and it is >> easily possible to disabled the new debugger through a setting. However, >> please do take the time to provide us feedback if something does not work >> out for you. We want to know what can be improved and we try to react as >> fast as we can. >> >> A practical change comes from the fact that the variables are manipulated >> through a GTInspector, which makes it cheaper to maintain in the longer run. >> >> While the first thing that will capture the attention is the default >> generic interface, the real power comes from the moldable nature of the >> debugger. Like all other GT tools, GTDebugger is also moldable by design. >> This means that we can construct custom debuggers for specific libraries at >> small costs (often measured in a couple of hundred lines of code). >> >> For example, the core configuration includes also the SUnit and the >> bytecode debugger. These are around 150 lines of code. Here is how the >> bytecode debugger looks like: >> >> >> >> You can find more information in an introductory overview blog post that >> also includes some links for further reading: >> >> http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ >> >> Please let us know what you think. >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "What is more important: To be happy, or to make happy?" >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > >

Jan. 8, 2016

Re: [Pharo-dev] Changing performance balance between CPU & non-volatile storage

by Stephan Eggermont

On 07-01-16 20:07, Ben Coman wrote: > An enlightening article (if a bit long). I wonder how non-volatile > storage being faster than a CPU might affect Pharo systems. Perhaps > the importance of migrating between live and backup Images gains in > importance to backups via files. I'm not sure what to think about it. I find it an rather vague and badly written article. 100K iops is not close to saturating what a CPU core can process. The problem is the communication and the article does a really good job at confusing me about that. Further, commercial pricing is value based, not cost. Stephan

Jan. 8, 2016