May 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] MC Filetree -- missing FiletreeURL ?

by stephane ducasse

> I want a minimal Smalltalk with decent modularity semantics. We have been working on that since Pharo day one and we will continue. > I want > decent integration with the standard tools of the trade. I _don't_ > want to require special unique snowflake tools to work with my code. Ok > Right now I'm breaking up the Squeak Trunk into pieces, unloading > things as I go. I hope, at some stage, to end up with some fairly > minimal thing that will still allow one to load the main things that > Squeak's used for. To me minimality can be a trap. We want to empower users. if you goal is to make smalltalk used with normal tool, I do not really understand why you do not focus on making Pharo fully working with Git. > Colin Putney's Environments work is the main thrust > for 4.5, together with the usual cruft removal work. We are doing that since years but if you want to spend your energy on that this is your decision. > But I see your point about lack of vision, whether perceived or > actual. That's something Squeak will have to work on. I even wrote 40 pages to describe that we will get a minimal image with no compiler, we have tanker and candle light that are starting to work and we dreamed about it with pavel back in 2005. But this is your time and energy. :) Just be ready for competition because we are going there for real. There are so many exciting paths (type inferences, real modules, git back end) that I do not understand why you just redo what we did. May be this is something that you want to prove to yourself and this is ok too. >> Most of the pharo people are not payed for doing pharo. What we are building (and fighting for) is an >> ecosystem in which smart guys can also find a job and it is becoming to happen. Mariano is full of work >> and many others. Sean told me that he got several job offers. >> >> Pharo is not the end, it is the start. It is not like we would like it to be but everyday it gets closer to it. > > That's good to hear. I feel the same way about Squeak, although it's > clearly a lot, er, *mossier* than Pharo. > > frank >

May 24, 2013

Re: [Pharo-dev] Corrupt BlockClosure

by Max Leske

I played around with reverting the method and serializing but that doesn't change anything (the existing BlockClosure is obviously not modified). Then I thought that maybe the method was changed during a running DFSession but still couldn't reproduce. @Roberto Can you tell us anything about what you did befor / during / after running your session? On 24.05.2013, at 06:44, Max Leske <maxleske(a)gmail.com> wrote: > > On 23.05.2013, at 22:58, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> Hi, >> >> This is indeed strange, the BlockClosure has an incorrect startpc (31 instead of 43). You can fix it with: >> theBlock instVar: 2 put: 43. >> The wrong startpc corresponds to the beginning of the block in the previous version of the method (DFSession>>#numberOfMethodCalls), but I don't know why. > > Would it help to recompile the method? > >> I don't know fuel enough but could it be because the method of the block changed between serialization and materialization? > > No, there was never a materialization of that session. > >> >> Camille >> >> On 23 mai 2013, at 21:02, Max Leske wrote: >> >>> Hi Marcus >>> >>> Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. >>> >>> The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. >>> To see the stack, right click on the only entry in the right window and click "export session". You'll find the corrupt BlockClosure at BlockClosure>>fuelAccept: >>> >>> @Roberto >>> Is it possible to reproduce the stack with a new session? Or did this only happen once? >>> >>> >>> Cheers, >>> Max >>> >>> >>> Begin forwarded message: >>> >>>> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >>>> Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 >>>> Date: 23. Mai 2013 14:23:45 MESZ >>>> To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>>> Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>>> >>>> Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. >>>> Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) >>>> Thanks! >>>> >>>> >>>> On Thu, May 23, 2013 at 8:41 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>> What's the compiled method? Is it a special one? Which selector in which class? >>>> >>>> Max >>>> >>>> On 23.05.2013, at 12:45, "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> wrote: >>>> >>>> > Hi, >>>> > >>>> > While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. >>>> > >>>> > I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). >>>> > >>>> > I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns <error in printString: evaluate "self printString" to debug>) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. >>>> > >>>> > Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. >>>> > >>>> > Thanks in advance, >>>> > Roby >>>> > >>>> > ############################################################################################ >>>> > ######################################### STACK#1 ########################################### >>>> > ########################################################################################### >>>> > CompiledMethod(Object)>>errorSubscriptBounds: >>>> > CompiledMethod(Object)>>at: >>>> > InstructionStream>>interpretNextInstructionFor: >>>> > CompiledMethod>>abstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... >>>> > BlockClosure>>on:do: >>>> > CompiledMethod>>abstractBytecodeMessageAt: >>>> > BlockClosure>>blockCreationBytecodeMessage >>>> > BlockClosure>>endPC >>>> > BlockClosure>>abstractBytecodeMessagesDo: >>>> > BlockClosure>>isClean >>>> > BlockClosure>>shouldBeSubstitutedByCleanCopy >>>> > BlockClosure>>fuelAccept: >>>> > FLFullGeneralMapper(FLLightGeneralMapper)>>mapAndTrace: >>>> > FLFullGlobalMapper>>mapAndTrace: in Block: [(anObject class == CompiledMethod... >>>> > FLLargeIdentityDictionary>>at:ifAbsent: >>>> > FLFullGlobalMapper>>mapAndTrace: >>>> > FLPluggableSubstitutionMapper>>mapAndTrace: >>>> > FLPluggableSubstitutionMapper>>mapAndTrace: >>>> > FLAnalysis>>mapAndTrace: >>>> > FLAnalysis>>run >>>> > FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... >>>> > FLAnalyzer>>analysisFor: >>>> > FLSerialization>>analysisStep >>>> > FLSerialization>>run >>>> > DFSerializer(FLSerializer)>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... >>>> > DFSerializer(FLSerializer)>>serialize:on: in Block: [:anEncoder | ... >>>> > FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] >>>> > BlockClosure>>ensure: >>>> > FLEncoder class>>on:globalEnvironment:do: >>>> > DFSerializer(FLSerializer)>>serialize:on: >>>> > >>>> > >>>> > ############################################################################################ >>>> > ######################################### STACK#2 ########################################### >>>> > ############################################################################################ >>>> > Decompiler(Object)>>error: >>>> > Decompiler>>decompileBlock: >>>> > BlockClosure>>decompile >>>> > BlockClosure>>printOn: >>>> > BlockClosure(Object)>>printStringLimitedTo: in Block: [:s | self printOn: s] >>>> > String class(SequenceableCollection class)>>streamContents:limitedTo: >>>> > BlockClosure(Object)>>printStringLimitedTo: >>>> > BlockClosure(Object)>>printString >>>> > BlockClosure>>DoIt >>>> > Compiler>>evaluate:in:to:notifying:ifFail:logged: >>>> > SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... >>>> > BlockClosure>>on:do: >>>> > SmalltalkEditor>>evaluateSelectionAndDo: >>>> > SmalltalkEditor>>evaluateSelection >>>> > PluggableTextMorph>>doIt in Block: [textMorph editor evaluateSelection] >>>> > PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] >>>> > TextMorphForEditView(TextMorph)>>handleEdit: >>>> > PluggableTextMorph>>handleEdit: >>>> > PluggableTextMorph>>doIt >>>> > SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [:morph | morph doIt] >>>> > BlockClosure>>cull: >>>> > BlockClosure>>cull:cull: >>>> > BlockClosure>>cull:cull:cull: >>>> > KMCategoryTarget>>completeMatch:buffer: >>>> > KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [:l | l completeMatch: self buffer: aBuffer] >>>> > Array(SequenceableCollection)>>do: >>>> > KMKeymap>>notifyCompleteMatchTo:buffer: >>>> > KMKeymap>>onMatchWith:notify:andDo: >>>> > KMCategory>>onMatchWith:notify:andDo: in Block: [:entry | entry... >>>> > Set>>do: >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Pharo-fuel mailing list >>>> > Pharo-fuel(a)lists.gforge.inria.fr >>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>> >>>> _______________________________________________ >>>> Pharo-fuel mailing list >>>> Pharo-fuel(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> _______________________________________________ >>>> Pharo-fuel mailing list >>>> Pharo-fuel(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> >> >

May 24, 2013

Vote for GSOC project: SciSmalltalk

by Serge Stinckwich

Dear all, I have submitted a gsoc project called SciSmalltalk. This is a new Smalltalk project, similar to existing scientific libraries like NumPy, SciPy for Python or SciRuby for Ruby. SciSmalltalk already provide basic functionalities under MIT licence: complex and quaternions extensions, random number generator, fuzzy algorithms, LAPACK linear algebra package, Didier Besset's numerical methods, ... We want to extend SciSmalltalk to solve ODE (Ordinary Differential Equations). I you are a gsoc mentors, I would like to encourage you to give your vote to this project ! I believe this really important if we want to offer new alternatives for people who want to made science, mathematics, statistics and big data with Smalltalk ! The student for this project is very capable, because she is a mathematician student. We definitively need to support girls involvement in Smalltalk development and computer science ! Thank you. Regards, -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

May 24, 2013

Re: [Pharo-dev] Corrupt BlockClosure

by Max Leske

On 23.05.2013, at 22:58, Camille Teruel <camille.teruel(a)gmail.com> wrote: > Hi, > > This is indeed strange, the BlockClosure has an incorrect startpc (31 instead of 43). You can fix it with: > theBlock instVar: 2 put: 43. > The wrong startpc corresponds to the beginning of the block in the previous version of the method (DFSession>>#numberOfMethodCalls), but I don't know why. Would it help to recompile the method? > I don't know fuel enough but could it be because the method of the block changed between serialization and materialization? No, there was never a materialization of that session. > > Camille > > On 23 mai 2013, at 21:02, Max Leske wrote: > >> Hi Marcus >> >> Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. >> >> The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. >> To see the stack, right click on the only entry in the right window and click "export session". You'll find the corrupt BlockClosure at BlockClosure>>fuelAccept: >> >> @Roberto >> Is it possible to reproduce the stack with a new session? Or did this only happen once? >> >> >> Cheers, >> Max >> >> >> Begin forwarded message: >> >>> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >>> Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 >>> Date: 23. Mai 2013 14:23:45 MESZ >>> To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>> Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>> >>> Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. >>> Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) >>> Thanks! >>> >>> >>> On Thu, May 23, 2013 at 8:41 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> What's the compiled method? Is it a special one? Which selector in which class? >>> >>> Max >>> >>> On 23.05.2013, at 12:45, "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> wrote: >>> >>> > Hi, >>> > >>> > While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. >>> > >>> > I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). >>> > >>> > I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns <error in printString: evaluate "self printString" to debug>) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. >>> > >>> > Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. >>> > >>> > Thanks in advance, >>> > Roby >>> > >>> > ############################################################################################ >>> > ######################################### STACK#1 ########################################### >>> > ########################################################################################### >>> > CompiledMethod(Object)>>errorSubscriptBounds: >>> > CompiledMethod(Object)>>at: >>> > InstructionStream>>interpretNextInstructionFor: >>> > CompiledMethod>>abstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... >>> > BlockClosure>>on:do: >>> > CompiledMethod>>abstractBytecodeMessageAt: >>> > BlockClosure>>blockCreationBytecodeMessage >>> > BlockClosure>>endPC >>> > BlockClosure>>abstractBytecodeMessagesDo: >>> > BlockClosure>>isClean >>> > BlockClosure>>shouldBeSubstitutedByCleanCopy >>> > BlockClosure>>fuelAccept: >>> > FLFullGeneralMapper(FLLightGeneralMapper)>>mapAndTrace: >>> > FLFullGlobalMapper>>mapAndTrace: in Block: [(anObject class == CompiledMethod... >>> > FLLargeIdentityDictionary>>at:ifAbsent: >>> > FLFullGlobalMapper>>mapAndTrace: >>> > FLPluggableSubstitutionMapper>>mapAndTrace: >>> > FLPluggableSubstitutionMapper>>mapAndTrace: >>> > FLAnalysis>>mapAndTrace: >>> > FLAnalysis>>run >>> > FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... >>> > FLAnalyzer>>analysisFor: >>> > FLSerialization>>analysisStep >>> > FLSerialization>>run >>> > DFSerializer(FLSerializer)>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... >>> > DFSerializer(FLSerializer)>>serialize:on: in Block: [:anEncoder | ... >>> > FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] >>> > BlockClosure>>ensure: >>> > FLEncoder class>>on:globalEnvironment:do: >>> > DFSerializer(FLSerializer)>>serialize:on: >>> > >>> > >>> > ############################################################################################ >>> > ######################################### STACK#2 ########################################### >>> > ############################################################################################ >>> > Decompiler(Object)>>error: >>> > Decompiler>>decompileBlock: >>> > BlockClosure>>decompile >>> > BlockClosure>>printOn: >>> > BlockClosure(Object)>>printStringLimitedTo: in Block: [:s | self printOn: s] >>> > String class(SequenceableCollection class)>>streamContents:limitedTo: >>> > BlockClosure(Object)>>printStringLimitedTo: >>> > BlockClosure(Object)>>printString >>> > BlockClosure>>DoIt >>> > Compiler>>evaluate:in:to:notifying:ifFail:logged: >>> > SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... >>> > BlockClosure>>on:do: >>> > SmalltalkEditor>>evaluateSelectionAndDo: >>> > SmalltalkEditor>>evaluateSelection >>> > PluggableTextMorph>>doIt in Block: [textMorph editor evaluateSelection] >>> > PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] >>> > TextMorphForEditView(TextMorph)>>handleEdit: >>> > PluggableTextMorph>>handleEdit: >>> > PluggableTextMorph>>doIt >>> > SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [:morph | morph doIt] >>> > BlockClosure>>cull: >>> > BlockClosure>>cull:cull: >>> > BlockClosure>>cull:cull:cull: >>> > KMCategoryTarget>>completeMatch:buffer: >>> > KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [:l | l completeMatch: self buffer: aBuffer] >>> > Array(SequenceableCollection)>>do: >>> > KMKeymap>>notifyCompleteMatchTo:buffer: >>> > KMKeymap>>onMatchWith:notify:andDo: >>> > KMCategory>>onMatchWith:notify:andDo: in Block: [:entry | entry... >>> > Set>>do: >>> > >>> > >>> > >>> > _______________________________________________ >>> > Pharo-fuel mailing list >>> > Pharo-fuel(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> >>> _______________________________________________ >>> Pharo-fuel mailing list >>> Pharo-fuel(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> _______________________________________________ >>> Pharo-fuel mailing list >>> Pharo-fuel(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> >

May 24, 2013

Re: [Pharo-dev] DND refactoring

by Sean P. DeNigris

Carla F. Griggio wrote > Actually when I use Pharo I use the mouse quite a lot Actually, me too. But only because I don't know any good ways to do what I want with the keyboard :/ Carla F. Griggio wrote > I have the feeling that I'm not the only one using a lot the mouse, and > interactions like these would get along very well with that common user > behaviour. +1 Carla F. Griggio wrote > We actually already have some drag & drop refactorings, like moving a > method from one class to another one :) True. It'd be great to document all the cool UI things, especially the new ones. I guess I have no idea half the things I'm able to do in the IDE... ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-DND-refactoring-tp4689408p4689552.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 24, 2013

Re: [Pharo-dev] DND refactoring

by Carla F. Griggio

Actually when I use Pharo I use the mouse quite a lot. Maybe because I never got used to its shortcuts or I'm lazy to memorize them (at some point I had to re-learn them, and I was too lazy to do it :P). I have the feeling that I'm not the only one using a lot the mouse, and interactions like these would get along very well with that common user behaviour. We actually already have some drag & drop refactorings, like moving a method from one class to another one :) Great article, thanks Stephan! On Thu, May 23, 2013 at 10:50 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Stephan Eggermont wrote > > It has a nice demo video. It looks like something that could help > > reduce the current menu complexity. > > Pretty cool :) Personally, I avoid the mouse whenever possible, but it > would > be cool to have as an additional feature. > > - Sean > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Pharo-dev-DND-refactoring-tp4689408p4689533.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

May 23, 2013

Re: [Pharo-dev] Corrupt BlockClosure

by Camille Teruel

Hi, This is indeed strange, the BlockClosure has an incorrect startpc (31 instead of 43). You can fix it with: theBlock instVar: 2 put: 43. The wrong startpc corresponds to the beginning of the block in the previous version of the method (DFSession>>#numberOfMethodCalls), but I don't know why. I don't know fuel enough but could it be because the method of the block changed between serialization and materialization? Camille On 23 mai 2013, at 21:02, Max Leske wrote: > Hi Marcus > > Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. > > The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. > To see the stack, right click on the only entry in the right window and click "export session". You'll find the corrupt BlockClosure at BlockClosure>>fuelAccept: > > @Roberto > Is it possible to reproduce the stack with a new session? Or did this only happen once? > > > Cheers, > Max > > > Begin forwarded message: > >> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >> Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 >> Date: 23. Mai 2013 14:23:45 MESZ >> To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >> Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >> >> Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. >> Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) >> Thanks! >> >> >> On Thu, May 23, 2013 at 8:41 AM, Max Leske <maxleske(a)gmail.com> wrote: >> What's the compiled method? Is it a special one? Which selector in which class? >> >> Max >> >> On 23.05.2013, at 12:45, "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> wrote: >> >> > Hi, >> > >> > While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. >> > >> > I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). >> > >> > I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns <error in printString: evaluate "self printString" to debug>) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. >> > >> > Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. >> > >> > Thanks in advance, >> > Roby >> > >> > ############################################################################################ >> > ######################################### STACK#1 ########################################### >> > ########################################################################################### >> > CompiledMethod(Object)>>errorSubscriptBounds: >> > CompiledMethod(Object)>>at: >> > InstructionStream>>interpretNextInstructionFor: >> > CompiledMethod>>abstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... >> > BlockClosure>>on:do: >> > CompiledMethod>>abstractBytecodeMessageAt: >> > BlockClosure>>blockCreationBytecodeMessage >> > BlockClosure>>endPC >> > BlockClosure>>abstractBytecodeMessagesDo: >> > BlockClosure>>isClean >> > BlockClosure>>shouldBeSubstitutedByCleanCopy >> > BlockClosure>>fuelAccept: >> > FLFullGeneralMapper(FLLightGeneralMapper)>>mapAndTrace: >> > FLFullGlobalMapper>>mapAndTrace: in Block: [(anObject class == CompiledMethod... >> > FLLargeIdentityDictionary>>at:ifAbsent: >> > FLFullGlobalMapper>>mapAndTrace: >> > FLPluggableSubstitutionMapper>>mapAndTrace: >> > FLPluggableSubstitutionMapper>>mapAndTrace: >> > FLAnalysis>>mapAndTrace: >> > FLAnalysis>>run >> > FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... >> > FLAnalyzer>>analysisFor: >> > FLSerialization>>analysisStep >> > FLSerialization>>run >> > DFSerializer(FLSerializer)>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... >> > DFSerializer(FLSerializer)>>serialize:on: in Block: [:anEncoder | ... >> > FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] >> > BlockClosure>>ensure: >> > FLEncoder class>>on:globalEnvironment:do: >> > DFSerializer(FLSerializer)>>serialize:on: >> > >> > >> > ############################################################################################ >> > ######################################### STACK#2 ########################################### >> > ############################################################################################ >> > Decompiler(Object)>>error: >> > Decompiler>>decompileBlock: >> > BlockClosure>>decompile >> > BlockClosure>>printOn: >> > BlockClosure(Object)>>printStringLimitedTo: in Block: [:s | self printOn: s] >> > String class(SequenceableCollection class)>>streamContents:limitedTo: >> > BlockClosure(Object)>>printStringLimitedTo: >> > BlockClosure(Object)>>printString >> > BlockClosure>>DoIt >> > Compiler>>evaluate:in:to:notifying:ifFail:logged: >> > SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... >> > BlockClosure>>on:do: >> > SmalltalkEditor>>evaluateSelectionAndDo: >> > SmalltalkEditor>>evaluateSelection >> > PluggableTextMorph>>doIt in Block: [textMorph editor evaluateSelection] >> > PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] >> > TextMorphForEditView(TextMorph)>>handleEdit: >> > PluggableTextMorph>>handleEdit: >> > PluggableTextMorph>>doIt >> > SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [:morph | morph doIt] >> > BlockClosure>>cull: >> > BlockClosure>>cull:cull: >> > BlockClosure>>cull:cull:cull: >> > KMCategoryTarget>>completeMatch:buffer: >> > KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [:l | l completeMatch: self buffer: aBuffer] >> > Array(SequenceableCollection)>>do: >> > KMKeymap>>notifyCompleteMatchTo:buffer: >> > KMKeymap>>onMatchWith:notify:andDo: >> > KMCategory>>onMatchWith:notify:andDo: in Block: [:entry | entry... >> > Set>>do: >> > >> > >> > >> > _______________________________________________ >> > Pharo-fuel mailing list >> > Pharo-fuel(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >

May 23, 2013

Re: [Pharo-dev] DND refactoring

by Sean P. DeNigris

Stephan Eggermont wrote > It has a nice demo video. It looks like something that could help > reduce the current menu complexity. Pretty cool :) Personally, I avoid the mouse whenever possible, but it would be cool to have as an additional feature. - Sean ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-DND-refactoring-tp4689408p4689533.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 23, 2013

Re: [Pharo-dev] Messy Configurations

by stephane ducasse

> as you continue to push the boundaries of Smalltalk. Yes I like that expression :) Stef

May 23, 2013

Re: [Pharo-dev] MC should really write snaphsot/source.st in UTF8

by stephane ducasse

You know. I'm jealous. I'm jealous because I have to fight hard to concentrate and to get focused. So this is cool to see that some of you can. I have to handle so many tihngs that are still important to doâ¦ anyway keep get focused. Stef On May 23, 2013, at 4:19 PM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 23.05.2013 12:52, Nicolas Cellier wrote: >> The snapshot/source.st does not contain a mix of ByteString and WideString because a single String is written during the process (all code is written into a String new writeStream which will make the String wide at first wide Character), so it should work. >> > You're right, I mixed it with something (not quite sure what anymore) else... > It's been a while since I last looked at it, as indicated by the .cs timestamp :) > > Cheers, > Henry

May 23, 2013