Pharo-dev
By thread
pharo-dev@lists.pharo.org
By month
Messages by month
- ----- 2026 -----
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- 1 participants
- 144619 messages
Re: [Pharo-project] Alien Plugin for Linux
by Fernando olivero
Thanks for the information Noury!
Now we can safely assume the the official Alien package is in the Alien repository.
I will look into the answer from Henrik, and try to have a cleaner Alien-Core package, with less overrides.
Fernando
On Sep 29, 2010, at 8:11 PM, Noury Bouraqadi wrote:
> HI Fernando,
>
> It was a bug fix. And we hadn't at that time access to the Alien repo for saving it.
> Currently, we have a metacello config and it refers the alien repo.
>
> Noury
> On 29 sept. 2010, at 15:20, Fernando olivero wrote:
>
>> A question to the Ocean developers, why do have a particular Alien-Core package in the ocean repo? ( Alien-Core-LucFabresse.64.mcz )
>>
>> Are there some fixes that could be included in the official package? Please let me know so i can integrate them.
>>
>> I'm asking because i'm cleaning a bit the Alien mess, ( see previous mail) , and would like to have a single working official Alien.
>>
>> Thanks,
>> Fernando
>>
>> On Sep 29, 2010, at 12:56 PM, Fernando olivero wrote:
>>
>>> This Error prevents from using Alien in the lastest Pharo image.
>>>
>>> I will try to fix this today.
>>>
>>> Also i will remove the ConfigurationOfAlien from the Alien repository, because the version in MetacelloRepository should be used instead.
>>> So there are no future misunderstandings
>>>
>>>
>>> Thanks to Eliot, and using his precompiled Vms for all platforms Alien would be available now!
>>> (if the mentioned bug were fixed).
>>>
>>>
>>> Fernando
>>>
>>>
>>> On Sep 28, 2010, at 12:05 PM, Igor Stasenko wrote:
>>>
>>>> On 28 September 2010 11:51, Henrik Johansen
>>>> <henrik.s.johansen(a)veloxit.no> wrote:
>>>>> On Sep 28, 2010, at 10:34 16AM, Alberto Bacchelli wrote:
>>>>>
>>>>>> On 9/27/10 8:13 PM, Eliot Miranda wrote:
>>>>>>>
>>>>>>>
>>>>>>> 2010/9/27 Fernando olivero<fernando.olivero(a)usi.ch<mailto:fernando.olivero@usi.ch>>
>>>>>>> Does the prebuilt CogVM for linux include Alien support?
>>>>>>> http://www.mirandabanda.org/files/Cog/VM/VM.r2313/
>>>>>>>
>>>>>>> Only of the data manipulation and callout parts, not the callback parts. I'm trying to find time to work on integrating the Alien callback machinery with the FFI.
>>>>>>>
>>>>>>> best
>>>>>>> Eliot
>>>>>>
>>>>>> We had a problem after installing Alien,
>>>>>> when running the tests.
>>>>>>
>>>>>> The following does not understand
>>>>>>
>>>>>> MessageNotUnderstood: Array>>createMethod:header:methodClass:
>>>>>>
>>>>>> sent by
>>>>>> CompileMethod class>>newBytes:trailerBytes:nArgs:nTemps:nStack:nLits:primitive:
>>>>>>
>>>>>> It appears to be cog related, is it?
>>>>>>
>>>>>> Thank you,
>>>>>> Alberto
>>>>>
>>>>> No, it's Method-trailer related.
>>>>>
>>>>> IIRC, the convention used to be to pass the empty trailer bytes #(0 0 0 0), find the offending sender and change it to pass CompiledMethodTrailer empty instead.
>>>>>
>>>>
>>>> Right. A more compatible way is to use SomeClass defaultMethodTrailer
>>>> Where SomeClass should be a class, where you installing this method.
>>>>
>>>>
>>>>> Cheers,
>>>>> Henry
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pharo-project mailing list
>>>>> Pharo-project(a)lists.gforge.inria.fr
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>>
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> Pharo-project(a)lists.gforge.inria.fr
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project(a)lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Oct. 1, 2010
Re: [Pharo-project] NativeBoost and Cog. A working protype.
by Fernando olivero
Just a thought,
I would say that Lukas Helvetia framework could be used here, to cleanly embed C++, C or whatever you like syntax into the existing Smalltalk ambient.
So in the background NativeBoost would behave more uniformly, because everything in the end is smalltalk code.
Fernando
On Oct 1, 2010, at 8:39 AM, Schwab,Wilhelm K wrote:
> Sig,
>
> I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else) and in performance, unless you can stop boxing/unboxing the floats, which it sounds like you can't.
>
> One performance penalty that I look forward to suffering is to have an external library calling into Pharo to do function evaluations. In most cases, the number of operations will be small and the convenience of having the code in the image will be most welcome.
>
> Bill
>
>>> ......
>>> ________________________________________
>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen(a)pairhome.net]
>>> Sent: Thursday, September 30, 2010 11:33 AM
>>> To: Pharo-project(a)lists.gforge.inria.fr
>>> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>>>
>>> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote:
>>> On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
>>>> One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
>>>>
>>>> void LogOnePlus(double * data, unsigned long size)
>>>> /*
>>>> Add one and take log10() over the buffer; in-place transformation!
>>>> */
>>>> {
>>>> for(unsigned long i=0; i<size; i++){
>>>> data[i] = log10(data[i]+1);
>>>> }
>>>> }
>>>>
>>>> That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
>>>>
>>>
>>> Of course its possible.
>>> After porting C parser/compiler into smalltalk :)
>>> Or perhaps some meta-language which looks like C, but which easier to
>>> translate to native code.
>>>
Oct. 1, 2010
Re: [Pharo-project] NativeBoost and Cog. A working protype.
by Denis Kudriashov
Hello
2010/10/1 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>
> I'm pointing out that "do it all in Smalltalk" has limits, both in syntax
> (C++ is generally a better formula translator than Smalltalk; Smalltalk is
> better at expressing just about anything else)
I have many complex math stuff implemented in smalltalk and C in
university. And my experience that no matter C or smalltalk you use for
formula (equation) programming. In any case it will be not math formula like
on paper. And readability will be bad. Debugging is bad because of complex
calculations and diffirences in math formula and program language analogue.
Just see fast fourier transformation. Equations is not so complex. But
programme implementation...
Ideally programming math formula or equation should not exists for user. You
just put native math formula presentation to system and get results.
Maybe similar solution exists?
Oct. 1, 2010
Re: [Pharo-project] [BUG]Alien class(Object)>>error:
by Fernando olivero
Hi Patricio, could you provide more information on the image you are using? And the vm ? and the OS ?
It seems to be an Alien related problem, and not Lumiere related. The last time i've updated the Configuration's it was working , but somethings have changed regarding Alien.
You should check out the thread Alien Plugin for Linux.
Steps to go:
1. fix Alien
2. make AlienOpenGL work
3. use Lumiere.
First try to have AlienOpenGL working, using the ConfigurationOfAlienOpenGL, once we get it working , then we go back to Lumiere.
( I'll will fix the ConfigurationOfLumiere in the meantime )
Thanks,
Fernando
pd: I would love to ditch AlienOpenGL as the OpenGL layer, and use the openGL port done by Igor using NativeBoost. It's more robust, faster and complete port.
On Sep 30, 2010, at 8:36 PM, Tudor Girba wrote:
> Welcome and thanks for the question. It would be so cool to get Lumiere back to light :).
>
> Cheers,
> Doru
>
>
> On 30 Sep 2010, at 20:29, Stéphane Ducasse wrote:
>
>> Welcome Patricio.
>>
>> Stef
>>
>> On Sep 30, 2010, at 6:31 PM, Patricio Plaza A. wrote:
>>
>>> Hi,
>>>
>>> I'm trying to load Lumiére framework executing the script in a workspace following the
>>> instruction in "http://www.squeaksource.com/Lumiere/" but I'm getting some warning and error during the installation.
>>>
>>> I'll appreciate any support to get successfully load of Lumiére.
>>>
>>> Best regards,
>>>
>>> Patricio.
>>>
>>>
>>> 30 September 2010 12:12:37 pm
>>>
>>> VM: Mac OS - intel - 1064 - Squeak4.1 of 17 April 2010 [latest update: #9957] Pharo Development 1.1
>>> Image: Pharo-1.1-11411 [Latest update: #11411]
>>>
>>> SecurityManager state:
>>> Restricted: false
>>> FileAccess: true
>>> SocketAccess: true
>>> Working Dir /Users/pplaza/Documents/Pharo-1.1-OneClick.app/Contents/Resources
>>> Trusted Dir /foobar/tooBar/forSqueak/bogus
>>> Untrusted Dir /Users/pplaza/Library/Preferences/Squeak/Internet/My Squeak
>>>
>>> 1)
>>> Message Warning:
>>>
>>> This package depends on the following classes:
>>> GluQuadricObject
>>> DisplayList
>>> You must resolve these dependencies before you will be able to load these definitions:
>>> DisplayList classSide>>generateOn:evaluating:
>>> DisplayList>>generateOn:evaluating:
>>> GluQuadricObject>>loadUnitAxisInto:
>>>
>>> 2)
>>> Message Error:
>>> Alien class(Object)>>error:
>>> Receiver: Alien
>>> Arguments and temporary variables:
>>> aString: 'SystemDictionary>>recreateSpecialObjectsArray appears incompatible'
>>> Receiver's instance variables:
>>> superclass: ByteArray
>>> methodDict: a MethodDictionary(size 131)
>>> format: 1026
>>> instanceVariables: nil
>>> organization: ('accessing' address dataSize freeAfter: pointer strcpy strcpyFro...etc...
>>> subclasses: {FFICallbackReturnValue. FFICallbackThunk}
>>> name: #Alien
>>> classPool: a Dictionary(#GCMallocedAliens->an AlienWeakTable #PlatformSizes->ni...etc...
>>> sharedPools: nil
>>> environment: a SystemDictionary(lots of globals)
>>> category: #'Alien-Core'
>>> traitComposition: {}
>>> localSelectors: nil
>>>
>>> Alien class>>ensureInSpecialObjectsArray
>>> Receiver: Alien
>>> Arguments and temporary variables:
>>> index: 53
>>> Receiver's instance variables:
>>> superclass: ByteArray
>>> methodDict: a MethodDictionary(size 131)
>>> format: 1026
>>> instanceVariables: nil
>>> organization: ('accessing' address dataSize freeAfter: pointer strcpy strcpyFro...etc...
>>> subclasses: {FFICallbackReturnValue. FFICallbackThunk}
>>> name: #Alien
>>> classPool: a Dictionary(#GCMallocedAliens->an AlienWeakTable #PlatformSizes->ni...etc...
>>> sharedPools: nil
>>> environment: a SystemDictionary(lots of globals)
>>> category: #'Alien-Core'
>>> traitComposition: {}
>>> localSelectors: nil
>>>
>>> Alien class>>initialize
>>> Receiver: Alien
>>> Arguments and temporary variables:
>>>
>>> Receiver's instance variables:
>>> superclass: ByteArray
>>> methodDict: a MethodDictionary(size 131)
>>> format: 1026
>>> instanceVariables: nil
>>> organization: ('accessing' address dataSize freeAfter: pointer strcpy strcpyFro...etc...
>>> subclasses: {FFICallbackReturnValue. FFICallbackThunk}
>>> name: #Alien
>>> classPool: a Dictionary(#GCMallocedAliens->an AlienWeakTable #PlatformSizes->ni...etc...
>>> sharedPools: nil
>>> environment: a SystemDictionary(lots of globals)
>>> category: #'Alien-Core'
>>> traitComposition: {}
>>> localSelectors: nil
>>>
>>> MCMethodDefinition>>postloadOver:
>>> Receiver: a MCMethodDefinition(Alien class>>initialize)
>>> Arguments and temporary variables:
>>> aDefinition: nil
>>> Receiver's instance variables:
>>> classIsMeta: true
>>> source: 'initialize
>>> "
>>> Alien initialize
>>> "
>>> PlatformSizes := nil.
>>> GCMallocedA...etc...
>>> category: #'class initialization'
>>> selector: #initialize
>>> className: #Alien
>>> timeStamp: 'kdt 9/25/2009 16:45'
>>>
>>> [] in [] in [] in MCMultiPackageLoader(MCPackageLoader)>>basicLoad
>>> Receiver: a MCMultiPackageLoader
>>> Arguments and temporary variables:
>>> ea: a MCMethodDefinition(Alien class>>initialize)
>>> Receiver's instance variables:
>>> requirements: #()
>>> unloadableDefinitions: a SortedCollection()
>>> obsoletions: a Dictionary()
>>> additions: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a ...etc...
>>> removals: an OrderedCollection()
>>> errorDefinitions: an OrderedCollection()
>>> provisions: a Set(#ScorePlayerMorph #MOPTestClassD #MetacelloGoferPackageTestCa...etc...
>>> methodAdditions: an OrderedCollection(a MethodAddition a MethodAddition a Metho...etc...
>>>
>>> [] in [] in OrderedCollection(Collection)>>do:displayingProgress:every:
>>> Receiver: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a MCMethodDefinition(Seq...etc...
>>> Arguments and temporary variables:
>>> <<error during printing>
>>> Receiver's instance variables:
>>> array: an Array(a MCOrganizationDefinition(#(#'Alien-Core')) a MCMethodDefiniti...etc...
>>> firstIndex: 1
>>> lastIndex: 329
>>>
>>> OrderedCollection>>do:
>>> Receiver: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a MCMethodDefinition(Seq...etc...
>>> Arguments and temporary variables:
>>> aBlock: [:each |
>>> | newLabel |
>>> (count = 0
>>> or: [count + 1 = size
>>> or: [(T...etc...
>>> index: 35
>>> Receiver's instance variables:
>>> array: an Array(a MCOrganizationDefinition(#(#'Alien-Core')) a MCMethodDefiniti...etc...
>>> firstIndex: 1
>>> lastIndex: 329
>>>
>>> [] in OrderedCollection(Collection)>>do:displayingProgress:every:
>>> Receiver: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a MCMethodDefinition(Seq...etc...
>>> Arguments and temporary variables:
>>> <<error during printing>
>>> Receiver's instance variables:
>>> array: an Array(a MCOrganizationDefinition(#(#'Alien-Core')) a MCMethodDefiniti...etc...
>>> firstIndex: 1
>>> lastIndex: 329
>>>
>>> [] in [] in ProgressInitiationException>>defaultMorphicAction
>>> Receiver: ProgressInitiationException:
>>> Arguments and temporary variables:
>>> progress: [:barValArg |
>>> | barVal return newBarSize |
>>> barVal := barValArg.
>>> ret...etc...
>>> result: #(nil)
>>> Receiver's instance variables:
>>> messageText: nil
>>> tag: nil
>>> signalContext: ProgressInitiationException(Exception)>>signal
>>> handlerContext: nil
>>> outerContext: nil
>>> workBlock: [:bar | self
>>> do: [:each |
>>> | newLabel |
>>> (count = 0
>>> or: ...etc...
>>> maxVal: 329
>>> minVal: 0
>>> aPoint: 474@88
>>> progressTitle: ''
>>>
>>> BlockClosure>>on:do:
>>> Receiver: [result := workBlock value: progress]
>>> Arguments and temporary variables:
>>> exception: ProgressNotification
>>> handlerAction: [:ex |
>>> ex extraParam isString
>>> ifTrue: [SystemProgressMorph un...etc...
>>> handlerActive: true
>>> Receiver's instance variables:
>>> outerContext: [] in ProgressInitiationException>>defaultMorphicAction
>>> startpc: 83
>>> numArgs: 0
>>>
>>> [] in ProgressInitiationException>>defaultMorphicAction
>>> Receiver: ProgressInitiationException:
>>> Arguments and temporary variables:
>>> progress: [:barValArg |
>>> | barVal return newBarSize |
>>> barVal := barValArg.
>>> ret...etc...
>>> result: #(nil)
>>> Receiver's instance variables:
>>> messageText: nil
>>> tag: nil
>>> signalContext: ProgressInitiationException(Exception)>>signal
>>> handlerContext: nil
>>> outerContext: nil
>>> workBlock: [:bar | self
>>> do: [:each |
>>> | newLabel |
>>> (count = 0
>>> or: ...etc...
>>> maxVal: 329
>>> minVal: 0
>>> aPoint: 474@88
>>> progressTitle: ''
>>>
>>> BlockClosure>>ensure:
>>> Receiver: [[result := workBlock value: progress]
>>> on: ProgressNotification
>>> do: [:ex |
>>> ex extr...etc...
>>> Arguments and temporary variables:
>>> aBlock: [SystemProgressMorph close: progress]
>>> complete: nil
>>> returnValue: nil
>>> Receiver's instance variables:
>>> outerContext: ProgressInitiationException>>defaultMorphicAction
>>> startpc: 77
>>> numArgs: 0
>>>
>>> ProgressInitiationException>>defaultMorphicAction
>>> Receiver: ProgressInitiationException:
>>> Arguments and temporary variables:
>>> progress: [:barValArg |
>>> | barVal return newBarSize |
>>> barVal := barValArg.
>>> ret...etc...
>>> result: #(nil)
>>> Receiver's instance variables:
>>> messageText: nil
>>> tag: nil
>>> signalContext: ProgressInitiationException(Exception)>>signal
>>> handlerContext: nil
>>> outerContext: nil
>>> workBlock: [:bar | self
>>> do: [:each |
>>> | newLabel |
>>> (count = 0
>>> or: ...etc...
>>> maxVal: 329
>>> minVal: 0
>>> aPoint: 474@88
>>> progressTitle: ''
>>>
>>> ProgressInitiationException>>defaultAction
>>> Receiver: ProgressInitiationException:
>>> Arguments and temporary variables:
>>>
>>> Receiver's instance variables:
>>> messageText: nil
>>> tag: nil
>>> signalContext: ProgressInitiationException(Exception)>>signal
>>> handlerContext: nil
>>> outerContext: nil
>>> workBlock: [:bar | self
>>> do: [:each |
>>> | newLabel |
>>> (count = 0
>>> or: ...etc...
>>> maxVal: 329
>>> minVal: 0
>>> aPoint: 474@88
>>> progressTitle: ''
>>>
>>> UndefinedObject>>handleSignal:
>>> Receiver: nil
>>> Arguments and temporary variables:
>>> exception: ProgressInitiationException:
>>> Receiver's instance variables:
>>> nil
>>>
>>> MethodContext(ContextPart)>>handleSignal:
>>> Receiver: BlockClosure>>on:do:
>>> Arguments and temporary variables:
>>> exception: ProgressInitiationException:
>>> val: nil
>>> Receiver's instance variables:
>>> sender: PasteUpMorph>>becomeActiveDuring:
>>> pc: 17
>>> stackp: 3
>>> method: (BlockClosure>>#on:do: "a CompiledMethod(885784576)")
>>> closureOrNil: nil
>>> receiver: [aBlock value]
>>>
>>> MethodContext(ContextPart)>>handleSignal:
>>> Receiver: BlockClosure>>on:do:
>>> Arguments and temporary variables:
>>> exception: ProgressInitiationException:
>>> val: nil
>>> Receiver's instance variables:
>>> sender: TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection
>>> pc: 17
>>> stackp: 3
>>> method: (BlockClosure>>#on:do: "a CompiledMethod(885784576)")
>>> closureOrNil: nil
>>> receiver: [rcvr class evaluatorClass new
>>> evaluate: self selection asString
>>> ...etc...
>>>
>>> MethodContext(ContextPart)>>handleSignal:
>>> Receiver: BlockClosure>>on:do:
>>> Arguments and temporary variables:
>>> exception: ProgressInitiationException:
>>> val: nil
>>> Receiver's instance variables:
>>> sender: [] in ProgressInitiationException>>defaultMorphicAction
>>> pc: 17
>>> stackp: 3
>>> method: (BlockClosure>>#on:do: "a CompiledMethod(885784576)")
>>> closureOrNil: nil
>>> receiver: [result := workBlock value: progress]
>>>
>>> MethodContext(ContextPart)>>handleSignal:
>>> Receiver: BlockClosure>>on:do:
>>> Arguments and temporary variables:
>>> exception: ProgressInitiationException:
>>> val: nil
>>> Receiver's instance variables:
>>> sender: [] in ProgressInitiationException>>defaultMorphicAction
>>> pc: 17
>>> stackp: 3
>>> method: (BlockClosure>>#on:do: "a CompiledMethod(885784576)")
>>> closureOrNil: nil
>>> receiver: [result := workBlock value: progress]
>>>
>>> MethodContext(ContextPart)>>handleSignal:
>>> Receiver: BlockClosure>>on:do:
>>> Arguments and temporary variables:
>>> exception: ProgressInitiationException:
>>> val: nil
>>> Receiver's instance variables:
>>> sender: [] in MCMultiPackageLoader(MCPackageLoader)>>basicLoad
>>> pc: 17
>>> stackp: 3
>>> method: (BlockClosure>>#on:do: "a CompiledMethod(885784576)")
>>> closureOrNil: nil
>>> receiver: [additions
>>> do: [:ea | self loadClassDefinition: ea]
>>> displayingPro...etc...
>>>
>>> ProgressInitiationException(Exception)>>signal
>>> Receiver: ProgressInitiationException:
>>> Arguments and temporary variables:
>>>
>>> Receiver's instance variables:
>>> messageText: nil
>>> tag: nil
>>> signalContext: ProgressInitiationException(Exception)>>signal
>>> handlerContext: nil
>>> outerContext: nil
>>> workBlock: [:bar | self
>>> do: [:each |
>>> | newLabel |
>>> (count = 0
>>> or: ...etc...
>>> maxVal: 329
>>> minVal: 0
>>> aPoint: 474@88
>>> progressTitle: ''
>>>
>>> ProgressInitiationException>>display:at:from:to:during:
>>> Receiver: ProgressInitiationException:
>>> Arguments and temporary variables:
>>> argString: ''
>>> argPoint: 474@88
>>> argMinVal: 0
>>> argMaxVal: 329
>>> argWorkBlock: [:bar | self
>>> do: [:each |
>>> | newLabel |
>>> (count = 0
>>> o...etc...
>>> Receiver's instance variables:
>>> messageText: nil
>>> tag: nil
>>> signalContext: ProgressInitiationException(Exception)>>signal
>>> handlerContext: nil
>>> outerContext: nil
>>> workBlock: [:bar | self
>>> do: [:each |
>>> | newLabel |
>>> (count = 0
>>> or: ...etc...
>>> maxVal: 329
>>> minVal: 0
>>> aPoint: 474@88
>>> progressTitle: ''
>>>
>>> ProgressInitiationException class>>display:at:from:to:during:
>>> Receiver: ProgressInitiationException
>>> Arguments and temporary variables:
>>> aString: ''
>>> aPoint: 474@88
>>> minVal: 0
>>> maxVal: 329
>>> workBlock: [:bar | self
>>> do: [:each |
>>> | newLabel |
>>> (count = 0
>>> or: ...etc...
>>> Receiver's instance variables:
>>> superclass: Exception
>>> methodDict: a MethodDictionary(#defaultAction->(ProgressInitiationException>>#d...etc...
>>> format: 150
>>> instanceVariables: #('workBlock' 'maxVal' 'minVal' 'aPoint' 'progressTitle')
>>> organization: ('as yet unclassified' defaultAction defaultMorphicAction display...etc...
>>> subclasses: nil
>>> name: #ProgressInitiationException
>>> classPool: nil
>>> sharedPools: nil
>>> environment: a SystemDictionary(lots of globals)
>>> category: #'Morphic-Widgets'
>>> traitComposition: {}
>>> localSelectors: nil
>>>
>>> ByteString(String)>>displayProgressAt:from:to:during:
>>> Receiver: ''
>>> Arguments and temporary variables:
>>> aPoint: 474@88
>>> minVal: 0
>>> maxVal: 329
>>> workBlock: [:bar | self
>>> do: [:each |
>>> | newLabel |
>>> (count = 0
>>> or: ...etc...
>>> Receiver's instance variables:
>>> ''
>>>
>>> OrderedCollection(Collection)>>do:displayingProgress:every:
>>> Receiver: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a MCMethodDefinition(Seq...etc...
>>> Arguments and temporary variables:
>>> <<error during printing>
>>> Receiver's instance variables:
>>> array: an Array(a MCOrganizationDefinition(#(#'Alien-Core')) a MCMethodDefiniti...etc...
>>> firstIndex: 1
>>> lastIndex: 329
>>>
>>> OrderedCollection(Collection)>>do:displayingProgress:
>>> Receiver: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a MCMethodDefinition(Seq...etc...
>>> Arguments and temporary variables:
>>> aBlock: [:ea | ea
>>> postloadOver: (self obsoletionFor: ea)]
>>> aStringOrBlock: 'Initializing...'
>>> Receiver's instance variables:
>>> array: an Array(a MCOrganizationDefinition(#(#'Alien-Core')) a MCMethodDefiniti...etc...
>>> firstIndex: 1
>>> lastIndex: 329
>>>
>>> [] in [] in MCMultiPackageLoader(MCPackageLoader)>>basicLoad
>>> Receiver: a MCMultiPackageLoader
>>> Arguments and temporary variables:
>>>
>>> Receiver's instance variables:
>>> requirements: #()
>>> unloadableDefinitions: a SortedCollection()
>>> obsoletions: a Dictionary()
>>> additions: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a ...etc...
>>> removals: an OrderedCollection()
>>> errorDefinitions: an OrderedCollection()
>>> provisions: a Set(#ScorePlayerMorph #MOPTestClassD #MetacelloGoferPackageTestCa...etc...
>>> methodAdditions: an OrderedCollection(a MethodAddition a MethodAddition a Metho...etc...
>>>
>>> BlockClosure>>on:do:
>>> Receiver: [additions
>>> do: [:ea | self loadClassDefinition: ea]
>>> displayingProgress: 'Loading class...etc...
>>> Arguments and temporary variables:
>>> exception: InMidstOfFileinNotification
>>> handlerAction: [:n | n resume: true]
>>> handlerActive: true
>>> Receiver's instance variables:
>>> outerContext: [] in MCMultiPackageLoader(MCPackageLoader)>>basicLoad
>>> startpc: 112
>>> numArgs: 0
>>>
>>> [] in MCMultiPackageLoader(MCPackageLoader)>>basicLoad
>>> Receiver: a MCMultiPackageLoader
>>> Arguments and temporary variables:
>>>
>>> Receiver's instance variables:
>>> requirements: #()
>>> unloadableDefinitions: a SortedCollection()
>>> obsoletions: a Dictionary()
>>> additions: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a ...etc...
>>> removals: an OrderedCollection()
>>> errorDefinitions: an OrderedCollection()
>>> provisions: a Set(#ScorePlayerMorph #MOPTestClassD #MetacelloGoferPackageTestCa...etc...
>>> methodAdditions: an OrderedCollection(a MethodAddition a MethodAddition a Metho...etc...
>>>
>>> BlockClosure>>ensure:
>>> Receiver: [[additions
>>> do: [:ea | self loadClassDefinition: ea]
>>> displayingProgress: 'Loading clas...etc...
>>> Arguments and temporary variables:
>>> aBlock: [self flushChangesFile]
>>> complete: nil
>>> returnValue: nil
>>> Receiver's instance variables:
>>> outerContext: MCMultiPackageLoader(MCPackageLoader)>>basicLoad
>>> startpc: 108
>>> numArgs: 0
>>>
>>> MCMultiPackageLoader(MCPackageLoader)>>basicLoad
>>> Receiver: a MCMultiPackageLoader
>>> Arguments and temporary variables:
>>>
>>> Receiver's instance variables:
>>> requirements: #()
>>> unloadableDefinitions: a SortedCollection()
>>> obsoletions: a Dictionary()
>>> additions: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a ...etc...
>>> removals: an OrderedCollection()
>>> errorDefinitions: an OrderedCollection()
>>> provisions: a Set(#ScorePlayerMorph #MOPTestClassD #MetacelloGoferPackageTestCa...etc...
>>> methodAdditions: an OrderedCollection(a MethodAddition a MethodAddition a Metho...etc...
>>>
>>> [] in MCMultiPackageLoader(MCPackageLoader)>>loadWithNameLike:
>>> Receiver: a MCMultiPackageLoader
>>> Arguments and temporary variables:
>>>
>>> Receiver's instance variables:
>>> requirements: #()
>>> unloadableDefinitions: a SortedCollection()
>>> obsoletions: a Dictionary()
>>> additions: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a ...etc...
>>> removals: an OrderedCollection()
>>> errorDefinitions: an OrderedCollection()
>>> provisions: a Set(#ScorePlayerMorph #MOPTestClassD #MetacelloGoferPackageTestCa...etc...
>>> methodAdditions: an OrderedCollection(a MethodAddition a MethodAddition a Metho...etc...
>>>
>>> [] in MCMultiPackageLoader(MCPackageLoader)>>useChangeSetNamed:during:
>>> Receiver: a MCMultiPackageLoader
>>> Arguments and temporary variables:
>>> aBlock: [self basicLoad]
>>> Receiver's instance variables:
>>> requirements: #()
>>> unloadableDefinitions: a SortedCollection()
>>> obsoletions: a Dictionary()
>>> additions: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a ...etc...
>>> removals: an OrderedCollection()
>>> errorDefinitions: an OrderedCollection()
>>> provisions: a Set(#ScorePlayerMorph #MOPTestClassD #MetacelloGoferPackageTestCa...etc...
>>> methodAdditions: an OrderedCollection(a MethodAddition a MethodAddition a Metho...etc...
>>>
>>> BlockClosure>>ensure:
>>> Receiver: [aBlock value]
>>> Arguments and temporary variables:
>>> aBlock: [changeHolder newChanges: oldChanges]
>>> complete: nil
>>> returnValue: nil
>>> Receiver's instance variables:
>>> outerContext: MCMultiPackageLoader(MCPackageLoader)>>useChangeSetNamed:during:
>>> startpc: 93
>>> numArgs: 0
>>>
>>> MCMultiPackageLoader(MCPackageLoader)>>useChangeSetNamed:during:
>>> Receiver: a MCMultiPackageLoader
>>> Arguments and temporary variables:
>>> baseName: 'Alien-Core-LucFabresse.64'
>>> aBlock: [self basicLoad]
>>> changeHolder: ChangeSet
>>> oldChanges: a ChangeSet named Unnamed
>>> newChanges: a ChangeSet named Alien-Core-LucFabresse.64
>>> Receiver's instance variables:
>>> requirements: #()
>>> unloadableDefinitions: a SortedCollection()
>>> obsoletions: a Dictionary()
>>> additions: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a ...etc...
>>> removals: an OrderedCollection()
>>> errorDefinitions: an OrderedCollection()
>>> provisions: a Set(#ScorePlayerMorph #MOPTestClassD #MetacelloGoferPackageTestCa...etc...
>>> methodAdditions: an OrderedCollection(a MethodAddition a MethodAddition a Metho...etc...
>>>
>>> MCMultiPackageLoader(MCPackageLoader)>>useNewChangeSetNamedLike:during:
>>> Receiver: a MCMultiPackageLoader
>>> Arguments and temporary variables:
>>> baseName: 'Alien-Core-LucFabresse.64'
>>> aBlock: [self basicLoad]
>>> Receiver's instance variables:
>>> requirements: #()
>>> unloadableDefinitions: a SortedCollection()
>>> obsoletions: a Dictionary()
>>> additions: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a ...etc...
>>> removals: an OrderedCollection()
>>> errorDefinitions: an OrderedCollection()
>>> provisions: a Set(#ScorePlayerMorph #MOPTestClassD #MetacelloGoferPackageTestCa...etc...
>>> methodAdditions: an OrderedCollection(a MethodAddition a MethodAddition a Metho...etc...
>>>
>>> MCMultiPackageLoader(MCPackageLoader)>>loadWithNameLike:
>>> Receiver: a MCMultiPackageLoader
>>> Arguments and temporary variables:
>>> baseName: 'Alien-Core-LucFabresse.64'
>>> Receiver's instance variables:
>>> requirements: #()
>>> unloadableDefinitions: a SortedCollection()
>>> obsoletions: a Dictionary()
>>> additions: an OrderedCollection(a MCOrganizationDefinition(#(#'Alien-Core')) a ...etc...
>>> removals: an OrderedCollection()
>>> errorDefinitions: an OrderedCollection()
>>> provisions: a Set(#ScorePlayerMorph #MOPTestClassD #MetacelloGoferPackageTestCa...etc...
>>> methodAdditions: an OrderedCollection(a MethodAddition a MethodAddition a Metho...etc...
>>>
>>> MCVersionLoader>>loadWithNameLike:
>>> Receiver: a MCVersionLoader
>>> Arguments and temporary variables:
>>> aString: 'Alien-Core-LucFabresse.64'
>>> loader: a MCMultiPackageLoader
>>> Receiver's instance variables:
>>> versions: an OrderedCollection(a MCVersion(Alien-Core-LucFabresse.64) a MCVersi...etc...
>>>
>>> MCVersionLoader>>load
>>> Receiver: a MCVersionLoader
>>> Arguments and temporary variables:
>>>
>>> Receiver's instance variables:
>>> versions: an OrderedCollection(a MCVersion(Alien-Core-LucFabresse.64) a MCVersi...etc...
>>>
>>>
>>> --- The full stack ---
>>> Alien class(Object)>>error:
>>> Alien class>>ensureInSpecialObjectsArray
>>> Alien class>>initialize
>>> MCMethodDefinition>>postloadOver:
>>> [] in [] in [] in MCMultiPackageLoader(MCPackageLoader)>>basicLoad
>>> [] in [] in OrderedCollection(Collection)>>do:displayingProgress:every:
>>> OrderedCollection>>do:
>>> [] in OrderedCollection(Collection)>>do:displayingProgress:every:
>>> [] in [] in ProgressInitiationException>>defaultMorphicAction
>>> BlockClosure>>on:do:
>>> [] in ProgressInitiationException>>defaultMorphicAction
>>> BlockClosure>>ensure:
>>> ProgressInitiationException>>defaultMorphicAction
>>> ProgressInitiationException>>defaultAction
>>> UndefinedObject>>handleSignal:
>>> MethodContext(ContextPart)>>handleSignal:
>>> MethodContext(ContextPart)>>handleSignal:
>>> MethodContext(ContextPart)>>handleSignal:
>>> MethodContext(ContextPart)>>handleSignal:
>>> MethodContext(ContextPart)>>handleSignal:
>>> ProgressInitiationException(Exception)>>signal
>>> ProgressInitiationException>>display:at:from:to:during:
>>> ProgressInitiationException class>>display:at:from:to:during:
>>> ByteString(String)>>displayProgressAt:from:to:during:
>>> OrderedCollection(Collection)>>do:displayingProgress:every:
>>> OrderedCollection(Collection)>>do:displayingProgress:
>>> [] in [] in MCMultiPackageLoader(MCPackageLoader)>>basicLoad
>>> BlockClosure>>on:do:
>>> [] in MCMultiPackageLoader(MCPackageLoader)>>basicLoad
>>> BlockClosure>>ensure:
>>> MCMultiPackageLoader(MCPackageLoader)>>basicLoad
>>> [] in MCMultiPackageLoader(MCPackageLoader)>>loadWithNameLike:
>>> [] in MCMultiPackageLoader(MCPackageLoader)>>useChangeSetNamed:during:
>>> BlockClosure>>ensure:
>>> MCMultiPackageLoader(MCPackageLoader)>>useChangeSetNamed:during:
>>> MCMultiPackageLoader(MCPackageLoader)>>useNewChangeSetNamedLike:during:
>>> MCMultiPackageLoader(MCPackageLoader)>>loadWithNameLike:
>>> MCVersionLoader>>loadWithNameLike:
>>> MCVersionLoader>>load
>>> - - - - - - - - - - - - - - -
>>> - - - - - - - - - - - - - - - - - -
>>> MetacelloGoferLoad(GoferLoad)>>execute
>>> [] in [] in MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>>loadPackageDirective:gofer:
>>> [] in MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>>loadPackageDirective:gofer:
>>> [] in MetacelloPharoPlatform>>do:displaying:
>>> [] in [] in ProgressInitiationException>>defaultMorphicAction
>>> BlockClosure>>on:do:
>>> [] in ProgressInitiationException>>defaultMorphicAction
>>> BlockClosure>>ensure:
>>> ProgressInitiationException>>defaultMorphicAction
>>> ProgressInitiationException>>defaultAction
>>> UndefinedObject>>handleSignal:
>>> MethodContext(ContextPart)>>handleSignal:
>>> MethodContext(ContextPart)>>handleSignal:
>>> MethodContext(ContextPart)>>handleSignal:
>>> ProgressInitiationException(Exception)>>signal
>>> ProgressInitiationException>>display:at:from:to:during:
>>> ProgressInitiationException class>>display:at:from:to:during:
>>> ByteString(String)>>displayProgressAt:from:to:during:
>>> MetacelloPharoPlatform>>do:displaying:
>>> MetacelloLoadingMCSpecLoader(MetacelloCommonMCSpecLoader)>>loadPackageDirective:gofer:
>>> MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>>loadPackageDirective:gofer:
>>> MetacelloPackageLoadDirective>>loadUsing:gofer:
>>> [] in MetacelloAtomicLoadDirective(MetacelloVersionLoadDirective)>>loadLinearLoadDirective:gofer:
>>> OrderedCollection>>do:
>>> MetacelloAtomicLoadDirective(MetacelloVersionLoadDirective)>>loadLinearLoadDirective:gofer:
>>> MetacelloAtomicLoadDirective>>loadLinearLoadDirective:gofer:
>>> MetacelloLinearLoadDirective>>loadUsing:gofer:
>>> [] in MetacelloAtomicLoadDirective>>loadAtomicLoadDirective:gofer:
>>> OrderedCollection>>do:
>>> MetacelloAtomicLoadDirective>>loadAtomicLoadDirective:gofer:
>>> MetacelloAtomicLoadDirective>>loadUsing:gofer:
>>> [] in MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>>loadAtomicLoadDirective:gofer:
>>> OrderedCollection>>do:
>>> MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>>loadAtomicLoadDirective:gofer:
>>> MetacelloAtomicLoadDirective>>loadUsing:gofer:
>>> [] in MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>>loadLinearLoadDirective:gofer:
>>> OrderedCollection>>do:
>>> MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>>loadLinearLoadDirective:gofer:
>>> MetacelloLinearLoadDirective>>loadUsing:gofer:
>>> MetacelloLinearLoadDirective(MetacelloVersionLoadDirective)>>loadWithPolicy:
>>> MetacelloLoaderPolicy>>load
>>> MetacelloFetchingMCSpecLoader>>doLoad
>>> [] in [] in MetacelloMCVersion>>doLoadRequiredFromArray:
>>> [] in MetacelloPharoPlatform>>do:displaying:
>>> [] in [] in ProgressInitiationException>>defaultMorphicAction
>>> BlockClosure>>on:do:
>>> [] in ProgressInitiationException>>defaultMorphicAction
>>> BlockClosure>>ensure:
>>> ProgressInitiationException>>defaultMorphicAction
>>> ProgressInitiationException>>defaultAction
>>> UndefinedObject>>handleSignal:
>>> MethodContext(ContextPart)>>handleSignal:
>>> MethodContext(ContextPart)>>handleSignal:
>>> ProgressInitiationException(Exception)>>signal
>>> ProgressInitiationException>>display:at:from:to:during:
>>> ProgressInitiationException class>>display:at:from:to:during:
>>> ByteString(String)>>displayProgressAt:from:to:during:
>>> MetacelloPharoPlatform>>do:displaying:
>>> [] in MetacelloMCVersion>>doLoadRequiredFromArray:
>>> BlockClosure>>ensure:
>>> MetacelloMCVersion>>doLoadRequiredFromArray:
>>> MetacelloMCVersion>>load
>>> ConfigurationOfLumiere class>>loadDefault
>>> UndefinedObject>>DoIt
>>> Compiler>>evaluate:in:to:notifying:ifFail:logged:
>>> [] in TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection
>>> BlockClosure>>on:do:
>>> TextMorphForShoutEditor(ParagraphEditor)>>evaluateSelection
>>> TextMorphForShoutEditor(ParagraphEditor)>>doIt
>>> [] in TextMorphForShoutEditor(ParagraphEditor)>>doIt:
>>> TextMorphForShoutEditor(ParagraphEditor)>>terminateAndInitializeAround:
>>> TextMorphForShoutEditor(ParagraphEditor)>>doIt:
>>> TextMorphForShoutEditor(ParagraphEditor)>>dispatchOnKeyEvent:with:
>>> TextMorphForShoutEditor(TextMorphEditor)>>dispatchOnKeyEvent:with:
>>> TextMorphForShoutEditor(ParagraphEditor)>>keystroke:
>>> TextMorphForShoutEditor(TextMorphEditor)>>keystroke:
>>> [] in [] in TextMorphForShout(TextMorph)>>keyStroke:
>>> TextMorphForShout(TextMorph)>>handleInteraction:
>>> TextMorphForShout(TextMorphForEditView)>>handleInteraction:
>>> [] in TextMorphForShout(TextMorph)>>keyStroke:
>>> ECToolSet class>>codeCompletionAround:textMorph:keyStroke:
>>> DEVToolSet class>>codeCompletionAround:textMorph:keyStroke:
>>> ToolSet class>>codeCompletionAround:textMorph:keyStroke:
>>> TextMorphForShout(TextMorph)>>keyStroke:
>>> TextMorphForShout(TextMorphForEditView)>>keyStroke:
>>> TextMorphForShout(TextMorph)>>handleKeystroke:
>>> KeyboardEvent>>sentTo:
>>> TextMorphForShout(Morph)>>handleEvent:
>>> TextMorphForShout(Morph)>>handleFocusEvent:
>>> [] in HandMorph>>sendFocusEvent:to:clear:
>>> [] in PasteUpMorph>>becomeActiveDuring:
>>> BlockClosure>>on:do:
>>> PasteUpMorph>>becomeActiveDuring:
>>> HandMorph>>sendFocusEvent:to:clear:
>>> HandMorph>>sendEvent:focus:clear:
>>> HandMorph>>sendKeyboardEvent:
>>> HandMorph>>handleEvent:
>>> HandMorph>>processEvents
>>> [] in WorldState>>doOneCycleNowFor:
>>> Array(SequenceableCollection)>>do:
>>> WorldState>>handsDo:
>>> WorldState>>doOneCycleNowFor:
>>> WorldState>>doOneCycleFor:
>>> PasteUpMorph>>doOneCycle
>>> [] in Project class>>spawnNewProcess
>>> [] in BlockClosure>>newProcess
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project(a)lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> www.tudorgirba.com
>
> "Relationships are of two kinds: those we choose and those that happen. They both matter."
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Oct. 1, 2010
Re: [Pharo-project] NativeBoost and Cog. A working protype.
by Schwab,Wilhelm K
Sig,
I'm pointing out that "do it all in Smalltalk" has limits, both in syntax (C++ is generally a better formula translator than Smalltalk; Smalltalk is better at expressing just about anything else) and in performance, unless you can stop boxing/unboxing the floats, which it sounds like you can't.
One performance penalty that I look forward to suffering is to have an external library calling into Pharo to do function evaluations. In most cases, the number of operations will be small and the convenience of having the code in the image will be most welcome.
Bill
________________________________________
From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com]
Sent: Thursday, September 30, 2010 9:20 PM
To: Pharo-project(a)lists.gforge.inria.fr
Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
On 30 September 2010 22:56, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote:
> Sig,
>
> Another question, and I don't know the answer yet, involves something that is not done via NativeBoost but is instead "just left to Cog" to optimize. Will something like replacing a double array with log(abs(buffer[i])+1) be reliably translated? Some seem to be suggesting that stuff like that and worse will just magically be as fast as if one took the time to code a C function and put it in shared library. Maybe it will. Any ideas?
I'm not sure what you mean. Do you mean to make special #atLogAbs:
method, which reads an element from array , but before returning a
value calls log(abs(..))?
This will be faster with primitive, since smalltalk if you do that:
result := ((array at: i) abs+1) log.
It has to do boxing/unboxing the floats at each send.
>
> Not long enough, I got "the fail-over code for your PLUGIN (emphasis added) will take care of it" in response to questions about the vm's silent refusal to load functions from a library that was in fact the sole platform support for a piece of hardware. Even if there were backup Smalltalk code to talk to the device, it would not do the threading magic to run in the background, and it would not be fast enough to do the job.
>
> Less extreme but just as important are functions for Fourier and Wavelet Transforms, etc. I try to find shared libraries for such things, but there is invariably glue that might not be well supported and calls for some native code of some type, whether that comes from Cog, NativeBoost, or another function in a workhorse library of mine.
Not sure what you mean.
>
> Bill
>
>
>
> ________________________________________
> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com]
> Sent: Thursday, September 30, 2010 2:37 PM
> To: Pharo-project(a)lists.gforge.inria.fr
> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>
> On 30 September 2010 20:30, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote:
>> Work can be many things. Complicated equations are often better expressed in other languages, and where the line falls between having to deal with another language and tool set and study results (which one ultimately has to do anyway) vs. using Pharo's debugger to plow into what can be (can't believe I'm saying this<g>) a clumsy parenthesis-laden soup is hard to say. Smalltalk is great at control flow, interfacing (GUI and otherwise) - just about anything but looping over millions of bytes/ints/floats.
>>
>> The more I think about Cog and NativeBoost, the more I suspect I will find that many snippets like below will not be needed. One concern though: is there any amount of work that has to be done before something gets translated/cached as native code? Depending on count, cache size, granularity of the cached structures, it *might* be better to write the C and put it in a library so there is no question what will run as native code.
>>
>
> Its up to you, of course. The native code is held inside a compiled
> method(s), and once it generaetd not dismissed unless
> you instruct so. So, it doesn't matters how much time it takes to
> generate code, because it done once at first method invocation,
> and then dropped only if you change the method or do 'NativeBoost
> clearNativeCode'.
>
> Native code could even survive an image restarts, but i forcely
> clearing it when fresh image starts, because there is too much
> nuances, where it won't go (for instance, you were running image under
> Squeak VM, and then restarted it under Cog).
>
>> Bill
>>
>> ________________________________________
>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen(a)pairhome.net]
>> Sent: Thursday, September 30, 2010 11:33 AM
>> To: Pharo-project(a)lists.gforge.inria.fr
>> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>>
>> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote:
>> On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
>>> One really crazy idea: inline C. Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
>>>
>>> void LogOnePlus(double * data, unsigned long size)
>>> /*
>>> Add one and take log10() over the buffer; in-place transformation!
>>> */
>>> {
>>> for(unsigned long i=0; i<size; i++){
>>> data[i] = log10(data[i]+1);
>>> }
>>> }
>>>
>>> That's a simple calculation, but do it millions of times and it adds up. Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
>>>
>>
>> Of course its possible.
>> After porting C parser/compiler into smalltalk :)
>> Or perhaps some meta-language which looks like C, but which easier to
>> translate to native code.
>>
>> Indeed. It might be less work to just make the Smalltalk run as fast as the equivalent C code (using a bit of dynamic, run time optimization).
>>
>> - Stephen
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
_______________________________________________
Pharo-project mailing list
Pharo-project(a)lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Oct. 1, 2010
Re: [Pharo-project] "A Mentoring Course on Smalltalk" Code License
by Sean P. DeNigris
Andres Valloud-4 wrote:
>
> Well, since this discussion is public now :)
>
hee hee
Andres Valloud-4 wrote:
>
> ... exactly what seems to be
> the problem? The book talks about code that is often in the public
> Store repository. Is the problem that the code in the public Store
> repository doesn't have an MIT license? Or is the problem that the book
> that talks about the code in the public Store repository doesn't say
> "and the code has an MIT license"?
>
Would a license expert weigh in here? Andres, would it be difficult to add
a note to the book specifying that the code in it is MIT?
--
View this message in context: http://forum.world.st/A-Mentoring-Course-on-Smalltalk-Code-License-tp271425…
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Oct. 1, 2010
Re: [Pharo-project] NativeBoost and Cog. A working protype.
by Igor Stasenko
On 30 September 2010 22:56, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote:
> Sig,
>
> Another question, and I don't know the answer yet, involves something that is not done via NativeBoost but is instead "just left to Cog" to optimize. Â Will something like replacing a double array with log(abs(buffer[i])+1) be reliably translated? Â Some seem to be suggesting that stuff like that and worse will just magically be as fast as if one took the time to code a C function and put it in shared library. Â Maybe it will. Â Any ideas?
I'm not sure what you mean. Do you mean to make special #atLogAbs:
method, which reads an element from array , but before returning a
value calls log(abs(..))?
This will be faster with primitive, since smalltalk if you do that:
result := ((array at: i) abs+1) log.
It has to do boxing/unboxing the floats at each send.
>
> Not long enough, I got "the fail-over code for your PLUGIN (emphasis added) will take care of it" in response to questions about the vm's silent refusal to load functions from a library that was in fact the sole platform support for a piece of hardware. Â Even if there were backup Smalltalk code to talk to the device, it would not do the threading magic to run in the background, and it would not be fast enough to do the job.
>
> Less extreme but just as important are functions for Fourier and Wavelet Transforms, etc. Â I try to find shared libraries for such things, but there is invariably glue that might not be well supported and calls for some native code of some type, whether that comes from Cog, NativeBoost, or another function in a workhorse library of mine.
Not sure what you mean.
>
> Bill
>
>
>
> ________________________________________
> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com]
> Sent: Thursday, September 30, 2010 2:37 PM
> To: Pharo-project(a)lists.gforge.inria.fr
> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>
> On 30 September 2010 20:30, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote:
>> Work can be many things. Â Complicated equations are often better expressed in other languages, and where the line falls between having to deal with another language and tool set and study results (which one ultimately has to do anyway) vs. using Pharo's debugger to plow into what can be (can't believe I'm saying this<g>) a clumsy parenthesis-laden soup is hard to say. Â Smalltalk is great at control flow, interfacing (GUI and otherwise) - just about anything but looping over millions of bytes/ints/floats.
>>
>> The more I think about Cog and NativeBoost, the more I suspect I will find that many snippets like below will not be needed. Â One concern though: is there any amount of work that has to be done before something gets translated/cached as native code? Â Depending on count, cache size, granularity of the cached structures, it *might* be better to write the C and put it in a library so there is no question what will run as native code.
>>
>
> Its up to you, of course. The native code is held inside a compiled
> method(s), and once it generaetd not dismissed unless
> you instruct so. So, it doesn't matters how much time it takes to
> generate code, because it done once at first method invocation,
> and then dropped only if you change the method or do 'NativeBoost
> clearNativeCode'.
>
> Native code could even survive an image restarts, but i forcely
> clearing it when fresh image starts, because there is too much
> nuances, where it won't go (for instance, you were running image under
> Squeak VM, and then restarted it under Cog).
>
>> Bill
>>
>> ________________________________________
>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Stephen Pair [stephen(a)pairhome.net]
>> Sent: Thursday, September 30, 2010 11:33 AM
>> To: Pharo-project(a)lists.gforge.inria.fr
>> Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype.
>>
>> On Wed, Sep 29, 2010 at 11:41 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote:
>> On 30 September 2010 06:20, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote:
>>> One really crazy idea: inline C. Â Is there any way that one could put C code into a method, have it compiled and captured somehow as part of the image? Â Perhaps I am underestimating Cog and will soon not need to bother with stuff like this, but a recent addition was
>>>
>>> void LogOnePlus(double * data, unsigned long size)
>>> /*
>>> Â Â Â Â Add one and take log10() over the buffer; in-place transformation!
>>> */
>>> {
>>> Â Â Â Â for(unsigned long i=0; i<size; i++){
>>> Â Â Â Â data[i] = log10(data[i]+1);
>>> Â Â Â Â }
>>> }
>>>
>>> That's a simple calculation, but do it millions of times and it adds up. Â Even if Cog is sufficiently far reaching to translate such things, there are still times when C/C++ does a far nicer job of translating formulas than does Smalltalk. Â Like I said, it's a crazy idea, and if I have to choose, I'd rather have callbacks :)
>>>
>>
>> Of course its possible.
>> After porting C parser/compiler into smalltalk :)
>> Or perhaps some meta-language which looks like C, but which easier to
>> translate to native code.
>>
>> Indeed. Â It might be less work to just make the Smalltalk run as fast as the equivalent C code (using a bit of dynamic, run time optimization).
>>
>> - Stephen
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project(a)lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Best regards,
Igor Stasenko AKA sig.
Oct. 1, 2010
[Pharo-project] Help is now able to define where subbooks are placed
by Torsten Bergmann
Hi Enrico,
found the time this evening to integrate your idea
that custom help books should be able to define
where subbooks should be placed/displayed:
#pages
^(firstPage MyAppSubTutorial secondPage thirdPage)
Just update your Squeak image to #10565 and you dont
need to workaround this problem using a custom
builder anymore.
It is now also mentioned in the help systems help
itself. See chapter "STEP 7 - TIPS AND TRICKS".
I've also opened an issue together with the
changeset for Pharo 1.2 so that it will be
integrated in one of the next pharo updates.
http://code.google.com/p/pharo/issues/detail?id=3022
Thanks for the idea and initial code!
Bye
T.
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
Sept. 30, 2010
Re: [Pharo-project] Period at end of message pattern ?
by James Ladd
I should have posted the whole mehod.
It is not just the message pattern, but a method with temps and statements.
Sept. 30, 2010
Re: [Pharo-project] haltOnce and haltOnCount
by Alexandre Bergel
I used haltOnce quite often when I had to debug the rendering facilities in Mondrian.
Putting "self halt" in a drawOn: method can easily freeze your image.
Alexandre
On 30 Sep 2010, at 17:18, Hernan Wilkinson wrote:
> Hi,
> when are these messages used? what are the scenarios?
> I just want to understand why they are there...
>
> --
> Hernán Wilkinson
> Agile Software Development, Teaching & Coaching
> Mobile: +54 - 911 - 4470 - 7207
> email: hernan.wilkinson(a)10Pines.com
> site: http://www.10Pines.com
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Sept. 30, 2010