Re: [Pharo-project] NativeBoost and Cog. A working protype.
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-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguc...@gmail.com] Sent: Thursday, September 30, 2010 9:20 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype. On 30 September 2010 22:56, Schwab,Wilhelm K bsch...@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-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguc...@gmail.com] Sent: Thursday, September 30, 2010 2:37 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] NativeBoost and Cog. A working protype. On 30 September 2010 20:30, Schwab,Wilhelm K bsch...@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 thisg) 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-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stephen Pair [step...@pairhome.net] Sent: Thursday, September 30, 2010 11:33 AM To: Pharo-project@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
Re: [Pharo-project] [BUG]Alien class(Object)error:
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 classSidegenerateOn:evaluating:
DisplayListgenerateOn:evaluating:
GluQuadricObjectloadUnitAxisInto:
2)
Message Error:
Alien class(Object)error:
Receiver: Alien
Arguments and temporary variables:
aString:'SystemDictionaryrecreateSpecialObjectsArray
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 classensureInSpecialObjectsArray
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 classinitialize
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
MCMethodDefinitionpostloadOver:
Receiver: a MCMethodDefinition(Alien classinitialize)
Arguments and temporary variables:
Re: [Pharo-project] NativeBoost and Cog. A working protype.
Hello 2010/10/1 Schwab,Wilhelm K bsch...@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? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] NativeBoost and Cog. A working protype.
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-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stephen Pair
[step...@pairhome.net]
Sent: Thursday, September 30, 2010 11:33 AM
To: Pharo-project@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
siguc...@gmail.commailto:siguc...@gmail.com wrote:
On 30 September 2010 06:20, Schwab,Wilhelm K
bsch...@anest.ufl.edumailto:bsch...@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; isize; 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.
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Alien Plugin for Linux
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.johan...@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 oliverofernando.oliv...@usi.chmailto:fernando.oliv...@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: ArraycreateMethod:header:methodClass: sent by CompileMethod classnewBytes: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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12160
12160 - Issue 3022: Custom help books should be able to define where subbooks should be placed/displayed Issue 2980: dropping a text file into the host window raises an error -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12161 - #12172
Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [ANN 1.2] new pre-built 1.2Core#1272
https://gforge.inria.fr/frs/download.php/27544/PharoCore-1.2-12172.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
On Fri, 1 Oct 2010, Marcus Denker wrote: Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload If you didn't fix the migration code, then WeakFinalizationRegistry is still in the system. Details here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/154009.html Levente -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!
On Fri, 1 Oct 2010, Mariano Martinez Peck wrote: Thanks to everybody. I did what you say and now MessageTally time: [ECContextTest new testUntypedVarsOnly] - 3023 I've just commited OCompletion. And I didn't know TimeProfiler :) If you download http://www.squeaksource.com/OCompletion/Ocompletion-ul.67.mcz you'll get better results: [ ECContextTest new testUntypedVarsOnly ] timeToRun === 815 Levente cheers Mariano On Tue, Sep 28, 2010 at 1:43 PM, Levente Uzonyi le...@elte.hu wrote: On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: On 28.09.2010 01:43, Levente Uzonyi wrote: On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: On 28.09.2010 00:41, Levente Uzonyi wrote: On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: On 28.09.2010 00:07, Levente Uzonyi wrote: On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: 2010/9/27 Levente Uzonyi le...@elte.hu On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: IF you take a 1.1 core and just load OCompletion: MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907 If you load OCompletion and the rest of the dev image: MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137 However, IN pharo dev 1.0 it is MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405 sooo something has changed? As I said, SortedCollection is not suitable for this kind of usage. But in Pharo 1.0 OCompletion was doing the sameso? did SortedCollection chang between 1.0 and 1.1? No, something else changed. The same test is still 5x faster in 1.0 dev with the new code. TimeProfiler to the rescue: Preferences class ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms) PreferencesettingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup. Nice find. If you check my code, you'll find that I optimized that away. :) Levente Yes ,you moved it out of the actual sort loop :) Rewrite the methods in ECPreferences to use the new syntax: preference: category: description: type:, and you shouldn't even have to do that to get ok performance. IMHO, it's rather disturbing to see things like EC, where its preferences are actually separated tucked away in an ECPreferences class, only to be delegated from there over to Preferences... The preferences should be updated, but sending a message once is still better than 2k-30k times. Levente Sure, on the order of a couple of milliseconds difference. I keep forgetting the fact we generally have different definitions of what constitutes ok performance ;) 30k was a bit optimistic assumption. For example the Pharo 1.1 OneClick image has 3220 globals. The sortBlock asks for the preference twice per evaluation. SortedCollection uses a binary search during #add:. If we are optimistic, then the preference is asked 3220 * (3220 ln / 2 ln) * 2 times which is ~75k. In the same image the old code asked for the preference 2282899 times during the tests, while the new code did it only 398 times. If the preference is changed to return the value of a variable, then the difference is only 80 ms, otherwise it's 36.6 seconds. Levente Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
On 1 October 2010 12:06, Levente Uzonyi le...@elte.hu wrote: On Fri, 1 Oct 2010, Marcus Denker wrote: Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload If you didn't fix the migration code, then WeakFinalizationRegistry is still in the system. Details here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/154009.html You mean this not work: Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. should be Smalltalk forgetClass: WeakFinalizationRegistry logged: false. right? Levente -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] PluggableListMorphByItem getCurrentSelectionIndex access directly a non-initailized instance variable
In pharo 1.2, MorphicToolBuilderTests testGetListSelection raise an error. This error is caused by PluggableListMorphByItem getCurrentSelectionIndex, which looks like that: getCurrentSelectionIndex Answer the index of the current selection. | item | getIndexSelector == nil ifTrue: [^ 0]. item := model perform: getIndexSelector. ^ list findFirst: [ :x | x = item]. list is nil when runing the test. I guess that a better way is to use the accessor 'getList'. This method seems to make the correct initializations befor retrning the instance variable 'list'. When replacing by: getCurrentSelectionIndex Answer the index of the current selection. | item | getIndexSelector == nil ifTrue: [^ 0]. item := model perform: getIndexSelector. ^ self getList findFirst: [ :x | x = item]. The test pass. I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3028 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] SystemVersionTesttestDowngrade use a deprecated method
The test SystemVersionTesttestDowngrade use SytemVersion version, which is deprected. It raise a warning when running the tests in a pharo 1.2 core image. I opened an issue: http://code.google.com/p/pharo/issues/detail?id=3025colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficultystart=300 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] TextLint questions and feedback
Hi,
We did a change in the way the files are opened.
We could not reproduce the same issue but we could manage to reproduce
other encoding issues.
So, please try your file again and let us know.
Cheers,
2010/9/30 Mariano Martinez Peck marianop...@gmail.com:
On Thu, Sep 2, 2010 at 5:13 PM, Mariano Martinez Peck
marianop...@gmail.com wrote:
Sorry, I forgot another bug. A piece of my latex is like this:
\authorinfo{
Mariano Martinez Peck\affINRIA\affEMD \and
Noury Bouraqadi\affEMD \and
Marcus Denker\affINRIA \and
St\'ephane Ducasse\affINRIA \and
Luc Fabresse\affEMD
}{
$^1$RMoD Project-Team, Inria Lille--Nord Europe / Universit\'e Lille 1
\\
$^2$Universit\'e Lille Nord de France, Ecole des Mines de Douai
}{marianop...@gmail.com,
\{stephane.ducasse,marcus.denke...@inria.fr,\\\{noury.bouraqadi,luc.fabress...@mines-douai.fr}
\maketitle
I don't know why...but once I saved the file, the image frezzed for a
long time, and then, if finished and that part was replaced by this:
\authorinfo{
Mariano Martinez Peck\affINRIA\affEMD \and
Noury Bouraqadi\affEMD \and
Marcus Denker\affINRIA \and
St\'ephane Ducasse\affINRIA \and
Luc Fabresse\affEMD
}{
$^1$RMoD Project-Team, Inria Lille--Nord Europe /
[Pharo-project] [update 1.2] #12173
12173 - - Issue 3003: handleDisabledKey: is missing in Editor and subclasses - Issue 2963: systemOrganizer fixes. Thanks German Leiva and James Foester Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] CodeMorph text should return an instance of Text but return a String
In pharo 1.2, NewTextMorphTests#testFullMethodName raise an error. This error happen when calling: CodeMorph defaultStyledText | text attribute | text := self text. text addAttribute: ( self newTextColorAttribute: Color black ). ^ text. text is a string, and therefore it does not understand 'addAttribute'. The value return by 'text' depends on the value of the instance variable 'adapter'. adapter can have different values according the way we initialize the CodeMorph. One of them is: beFullMethodName aspect := #selector. adapter := [:selector| target methodClass name , '.' , self selectorWithArguments ]. The block return a String and I guess the right code should be beFullMethodName aspect := #selector. adapter := [:selector| (target methodClass name , '.' , self selectorWithArguments) asText ] ??. I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CodeMorph text should return an instance of Text but return a String
I just saw that there is propositions to remove CodeMorph: http://code.google.com/p/pharo/issues/detail?id=2902q=CodeMorphcolspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty So maybe the best fix will be to remove all the tests related ? :) 2010/10/1 Cyrille Delaunay cy.delau...@gmail.com In pharo 1.2, NewTextMorphTests#testFullMethodName raise an error. This error happen when calling: CodeMorph defaultStyledText | text attribute | text := self text. text addAttribute: ( self newTextColorAttribute: Color black ). ^ text. text is a string, and therefore it does not understand 'addAttribute'. The value return by 'text' depends on the value of the instance variable 'adapter'. adapter can have different values according the way we initialize the CodeMorph. One of them is: beFullMethodName aspect := #selector. adapter := [:selector| target methodClass name , '.' , self selectorWithArguments ]. The block return a String and I guess the right code should be beFullMethodName aspect := #selector. adapter := [:selector| (target methodClass name , '.' , self selectorWithArguments) asText ] ??. I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] ECompletion/OCompletion tests takes A LIFE!!
On Fri, Oct 1, 2010 at 11:08 AM, Levente Uzonyi le...@elte.hu wrote: On Fri, 1 Oct 2010, Mariano Martinez Peck wrote: Thanks to everybody. I did what you say and now MessageTally time: [ECContextTest new testUntypedVarsOnly] - 3023 I've just commited OCompletion. And I didn't know TimeProfiler :) If you download http://www.squeaksource.com/OCompletion/Ocompletion-ul.67.mcz you'll get better results: [ ECContextTest new testUntypedVarsOnly ] timeToRun === 815 Excellent. Thanks Levente Levente cheers Mariano On Tue, Sep 28, 2010 at 1:43 PM, Levente Uzonyi le...@elte.hu wrote: On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: On 28.09.2010 01:43, Levente Uzonyi wrote: On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: On 28.09.2010 00:41, Levente Uzonyi wrote: On Tue, 28 Sep 2010, Henrik Sperre Johansen wrote: On 28.09.2010 00:07, Levente Uzonyi wrote: On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: 2010/9/27 Levente Uzonyi le...@elte.hu On Mon, 27 Sep 2010, Mariano Martinez Peck wrote: IF you take a 1.1 core and just load OCompletion: MessageTally time: [ECContextTest new testUntypedVarsOnly] 20907 If you load OCompletion and the rest of the dev image: MessageTally time: [ECContextTest new testUntypedVarsOnly] 100137 However, IN pharo dev 1.0 it is MessageTally time: [ECContextTest new testUntypedVarsOnly] 7405 sooo something has changed? As I said, SortedCollection is not suitable for this kind of usage. But in Pharo 1.0 OCompletion was doing the sameso? did SortedCollection chang between 1.0 and 1.1? No, something else changed. The same test is still 5x faster in 1.0 dev with the new code. TimeProfiler to the rescue: Preferences class ecompletionCaseSensitive 1.0: (1725ms) 1.1 (19724ms) PreferencesettingValue which is there for backwards-compatability in 1.1 does both symbol creation and respondsTo:, so yeah, it's much slower than the old dictionary lookup. Nice find. If you check my code, you'll find that I optimized that away. :) Levente Yes ,you moved it out of the actual sort loop :) Rewrite the methods in ECPreferences to use the new syntax: preference: category: description: type:, and you shouldn't even have to do that to get ok performance. IMHO, it's rather disturbing to see things like EC, where its preferences are actually separated tucked away in an ECPreferences class, only to be delegated from there over to Preferences... The preferences should be updated, but sending a message once is still better than 2k-30k times. Levente Sure, on the order of a couple of milliseconds difference. I keep forgetting the fact we generally have different definitions of what constitutes ok performance ;) 30k was a bit optimistic assumption. For example the Pharo 1.1 OneClick image has 3220 globals. The sortBlock asks for the preference twice per evaluation. SortedCollection uses a binary search during #add:. If we are optimistic, then the preference is asked 3220 * (3220 ln / 2 ln) * 2 times which is ~75k. In the same image the old code asked for the preference 2282899 times during the tests, while the new code did it only 398 times. If the preference is changed to return the value of a variable, then the difference is only 80 ms, otherwise it's 36.6 seconds. Levente Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12174
12174 - Issue 2713: Changelist deserves some fixes Issue 3030: Remove Explain... code (again) Issue 3023: change the initial windows position strategy Issue 3028: PluggableListMorphByItem getCurrentSelectionIndex access directly a non-initailized instance variable -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
On Fri, 1 Oct 2010, Igor Stasenko wrote: On 1 October 2010 12:06, Levente Uzonyi le...@elte.hu wrote: On Fri, 1 Oct 2010, Marcus Denker wrote: Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload If you didn't fix the migration code, then WeakFinalizationRegistry is still in the system. Details here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/154009.html You mean this not work: Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. should be Smalltalk forgetClass: WeakFinalizationRegistry logged: false. right? Yes. Levente Levente -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
2010/10/1 Levente Uzonyi le...@elte.hu: On Fri, 1 Oct 2010, Igor Stasenko wrote: On 1 October 2010 12:06, Levente Uzonyi le...@elte.hu wrote: On Fri, 1 Oct 2010, Marcus Denker wrote: Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload If you didn't fix the migration code, then WeakFinalizationRegistry is still in the system. Details here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/154009.html You mean this not work: Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. should be Smalltalk forgetClass: WeakFinalizationRegistry logged: false. right? Yes. Thanks for noticing. Levente Levente -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] CodeMorph text should return an instance of Text but return a String
Yes, i've been busy so i couldn't finish this issue. Because CodeMorph comes from Gaucho, and until now there was no need for it in the Pharo-Core. so i will remove it, and possibly when the need arises will propose its re-inclusion. Fernando pd: the idea behind CodeMorph is to have a specialized NewTextMorph for dealing with Methods sources, Class definitions. But now i have second thoughts, because i have the impression that having diferent Editors ( subclasses of TextEditor or SmalltalkEditor) should do the trick. On Oct 1, 2010, at 12:02 PM, Cyrille Delaunay wrote: I just saw that there is propositions to remove CodeMorph: http://code.google.com/p/pharo/issues/detail?id=2902q=CodeMorphcolspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty So maybe the best fix will be to remove all the tests related ? :) 2010/10/1 Cyrille Delaunay cy.delau...@gmail.com In pharo 1.2, NewTextMorphTests#testFullMethodName raise an error. This error happen when calling: CodeMorph defaultStyledText | text attribute | text := self text. text addAttribute: ( self newTextColorAttribute: Color black ). ^ text. text is a string, and therefore it does not understand 'addAttribute'. The value return by 'text' depends on the value of the instance variable 'adapter'. adapter can have different values according the way we initialize the CodeMorph. One of them is: beFullMethodName aspect := #selector. adapter := [:selector| target methodClass name , '.' , self selectorWithArguments ]. The block return a String and I guess the right code should be beFullMethodName aspect := #selector. adapter := [:selector| (target methodClass name , '.' , self selectorWithArguments) asText ] ??. I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3031 ATT1..txt ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] NativeBoost and Cog. A working protype.
On Oct 1, 2010, at 2:39 AM, Schwab,Wilhelm K bsch...@anest.ufl.edu 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. Regarding syntax, I'm all in favor of using special purpose languages where it makes sense (but my intuition says that should be done sparingly or else everything will degenerate into an incomprehensible mess). In this case it would be very nice to think about a language designed specifically for expressing mathematical expressions rather than C++ (which btw I don't agree is better for expressing formulas...it's just different and perhaps closer to conventional mathematical syntax). Regarding performance, I think it's entirely possible to get similar performance to C++ in Smalltalk (or just about any other language for that matter)...however, I'm not aware of anything that can do this today. You could deal with the boxing/unboxing overhead with a sufficient amount of inlining based on runtime type analysis. Once fully inlined, you can apply more traditional optimization techniques. I don't even think this would be particularly hard to do (and to a degree it's all been done before), but it is a lot of work. As I said, I'm not aware of anything readily available that achieves these things. So, to get the performance you seek in a slightly more pleasing syntax (beauty is in the eye of the beholder), C++ may be your best bet for now. - Stephen ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Vm-dev] Re: is it possible to know the memory occupation (bytes) of an object?
Ok...I have just commited. If you want to review: http://code.google.com/p/pharo/issues/detail?id=3032 cheers Mariano On Tue, Sep 28, 2010 at 1:45 PM, Mariano Martinez Peck marianop...@gmail.com wrote: On Tue, Sep 28, 2010 at 11:11 AM, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On Sep 28, 2010, at 9:36 27AM, Mariano Martinez Peck wrote: On Tue, Sep 28, 2010 at 6:46 AM, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2010/9/27 Eliot Miranda eliot.mira...@gmail.com: On Mon, Sep 27, 2010 at 12:20 PM, Mariano Martinez Peck marianop...@gmail.com wrote: On Wed, Sep 22, 2010 at 12:34 PM, Mariano Martinez Peck marianop...@gmail.com wrote: On Wed, Sep 22, 2010 at 12:12 PM, Henrik Johansen henrik.s.johan...@veloxit.no wrote: On Sep 22, 2010, at 9:59 40AM, Adrian Lienhard wrote: Some notes: - What should be answered for small ints? 1 sizeInMemory --8. That's wrong. Shouldn't this answer 0? Philosophical question really, imo both 4 (Again, in 32bit images at least) and 0 would be correct answers in their own ways. 8 is definitely wrong though :) The method comment should probably highlight which definition is used. Sowhat should we consider for SmallInteger ? 4 bytes or 0 bytes? 0 bytes, obviously. The only space occupied by a SmallInteger is the space of the slot containing it. There is no SmallInteger object beyond the slot. Or from another POV, it's 4, the size of the slot. But we don't count the size of the slots, they are already counted in the containing object, that's why it should answer 0. Thanks for the answers. I finally let this: sizeInMemory Answer the number of bytes consumed by this instance including object header. | isCompact headerBytes contentBytes | SmallInteger occupy 0 bytes since the only space occupied by a SmallInteger is the space of the slot containing it. There is no SmallInteger object beyond the slot. From another POV, it could be 4, the size of the slot. But we don't count the size of the slots, they are already counted in the containing object, that's why it should answer 0. (self isMemberOf: SmallInteger) ifTrue: [^0]. contentBytes := self class instSize * Smalltalk wordSize. inst vars self class isVariable ifTrue:[ |bytesPerElement| bytesPerElement := self class isBytes ifTrue: [1] ifFalse: [4]. contentBytes := contentBytes + (self basicSize * bytesPerElement)]. isCompact := self class indexIfCompact 0. headerBytes := contentBytes 255 ifTrue: [ 3 * Smalltalk wordSize ] ifFalse: [isCompact ifTrue: [Smalltalk wordSize] ifFalse: [2 * Smalltalk wordSize]]. ^ headerBytes + contentBytes Now I wonder...maybe instead of doing this it is easier to have a primitive that just calls #internalByteSize: ? The problem of course is that it needs changes in the vm... cheers Mariano isMemberOf: is so quaint... Why not SmallIntegersizeInMemory SmallInteger occupy 0 bytes since the only space occupied by a SmallInteger is the space of the slot containing it. There is no SmallInteger object beyond the slot. From another POV, it could be 4, the size of the slot. But we don't count the size of the slots, they are already counted in the containing object, that's why it should answer 0. ^0 and remove that part from the Object implementation. U thanks Henrik for enlight me and teach me. Shame on me. I think that too much paper writting, ppt and admin tasks are killing me :( But don't worry, now I will come to code again! Hope to recover... :) Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1
Hi Mariano, 2010/10/1 Mariano Martinez Peck marianop...@gmail.com Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo 1.1 but based on PharoCore 1.1.1. The versions of the external packages is the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has integrated some fixes and the support for CogVM. This means that Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For CogVM we recommend to use the last binaries that can be found in http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ This CogVM version fixes the problem with Objects as methods, and thus, all the #run:with:with are working. This means that tools like TestCoverage and AutoTest are working correctly with CogVM. WHile some simple things now work there's definitely at least one bug remaining (perform:withArguments: doesn't work for objects-as-methods) and Nicolas tried a more demanding test (the coverage test from XTreams) and found problems; see http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033230.html. I'll be releasing a new VM that will fix the perform issue, but it remains to be seen whether the bugs Nicolas as found are fixed by this. So while .33 is better Cog still doesn't support objects-as-method correctly. HTH Eliot The link to the image is: https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Progress Report] Zinc HTTP Components
Cool! Stef On Oct 1, 2010, at 10:04 AM, Sven Van Caekenberghe wrote: Here is a quick progress report regarding the Zinc HTTP Components project. Please check the SqueakSource history for a all the details. The external documentation has not yet been updated ;-) I am very pleased that Matt Kennedy joined the project as a developer and is contributing lots of really important and interesting code - way to go Matt! Some highights are: - we now have cookie handling, authentication and credential objects - there is a new ZnUserAgent client that can do advanced authentication handles cookies, sessions and that can follow redirects - there is a ZnFixedClient that can reuse a connection to the same host/port - there is support for client side chunked and gzip decoding - there is an experimental server that keeps connections alive (unfinised) - support classes ZnUserAgentSession and ZnUserAgentSession - lots of refactorings, fixes and portability improvements - the number of unit tests has increased to 71 Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] haltOnce and haltOnCount
+ 1 really really important On Sep 30, 2010, at 11:38 PM, Alexandre Bergel wrote: 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.wilkin...@10pines.com site: http://www.10Pines.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] PharoCorePackageDependenciesTests make tests with packages not presents in pharo 1.2
Several tests from PharoCorePackageDependenciesTests raise errors because it specify packages not present in pharo 1.2: 'AST-Tests-Core' 'AST-Core' 'AST-Semantic' The error come from: referencesInPackageNamed: pkgNameAsString | pi | pi := PackageOrganizer default packageNamed: pkgNameAsString ifAbsent: [^ self]. The package is not found, therefore it returns 'self', later in the code we iterate on that 'self', it raise a DNU Message. Maybe rather that returning self, we should return a more explicit error so that we know directly where does the problem comes from? Anyway, I guess the main problem here is that the packages specified are not present in the image? I opened an issue:http://code.google.com/p/pharo/issues/detail?id=3033 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Progress Report] Zinc HTTP Components
Wow, very impressive. What I would like to see is some kind of high-level API for convenient access to all features. Something along response := ZnHttp new url: 'http://www.foo.com'; userAgent: 'FakeAgent'; cookieAt: 'something' put: '123'; parameterAt: 'q' put: 'smalltalk'; onFailure: [ :error | self inform: 'failed' ]; onProgress: [ :status | ... ]; get Lukas On 1 October 2010 13:52, Stéphane Ducasse stephane.duca...@inria.fr wrote: Cool! Stef On Oct 1, 2010, at 10:04 AM, Sven Van Caekenberghe wrote: Here is a quick progress report regarding the Zinc HTTP Components project. Please check the SqueakSource history for a all the details. The external documentation has not yet been updated ;-) I am very pleased that Matt Kennedy joined the project as a developer and is contributing lots of really important and interesting code - way to go Matt! Some highights are: - we now have cookie handling, authentication and credential objects - there is a new ZnUserAgent client that can do advanced authentication handles cookies, sessions and that can follow redirects - there is a ZnFixedClient that can reuse a connection to the same host/port - there is support for client side chunked and gzip decoding - there is an experimental server that keeps connections alive (unfinised) - support classes ZnUserAgentSession and ZnUserAgentSession - lots of refactorings, fixes and portability improvements - the number of unit tests has increased to 71 Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] loading groups with metacello
Hi Mariano,
You already saw my problem.
With this you can check what is happening:
(ConfigurationOfGlamour project version: 'default') record: #('Core' 'Tests'
'Extras')
all the pre-requisites are being loaded and not only the groups.
Regards,
Veronica
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] loading groups with metacello
On Fri, Oct 1, 2010 at 2:16 PM, Veronica Isabel Uquillas Gomez
vuqui...@vub.ac.be wrote:
Hi Mariano,
You already saw my problem.
With this you can check what is happening:
(ConfigurationOfGlamour project version: 'default') record: #('Core'
'Tests' 'Extras')
I don't understand why this loads Grease for example.
Dale any idea? I checked loadDirective but I didn't understand.
Cheers
Mariano
all the pre-requisites are being loaded and not only the groups.
Regards,
Veronica
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Fix of Create button in Debugger (#3010 and #3011)
Hi all, We integrate the fix proposed by Hernan for #3010 and #3011. Hernan, thanks a lot for your fix proposal. Next time, just test it before on the latest Pharo (curently 1.2 and not 1.1) to make the integration easier. Thanks, Luc ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Progress Report] Zinc HTTP Components
Lukas, On 01 Oct 2010, at 14:10, Lukas Renggli wrote: What I would like to see is some kind of high-level API for convenient access to all features. Something along response := ZnHttp new url: 'http://www.foo.com'; userAgent: 'FakeAgent'; cookieAt: 'something' put: '123'; parameterAt: 'q' put: 'smalltalk'; onFailure: [ :error | self inform: 'failed' ]; onProgress: [ :status | ... ]; get A bit like Gofer I guess... It certainly looks cool, the code above. I'll have to think a little bit about that approach. How should such an object handle wrong use of the API ? What if I don't specify an url, do the get before setting the cookie, ... It feels as if there will be little feedback in terms of errors, no ? Sven ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
Igor Can you have a look because right now in 12174 I cannot do any update anymore so - either we fix it now or we have to rollbakc to 12161. Thanks. On Oct 1, 2010, at 12:49 PM, Igor Stasenko wrote: 2010/10/1 Levente Uzonyi le...@elte.hu: On Fri, 1 Oct 2010, Igor Stasenko wrote: On 1 October 2010 12:06, Levente Uzonyi le...@elte.hu wrote: On Fri, 1 Oct 2010, Marcus Denker wrote: Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload If you didn't fix the migration code, then WeakFinalizationRegistry is still in the system. Details here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/154009.html You mean this not work: Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. should be Smalltalk forgetClass: WeakFinalizationRegistry logged: false. right? Yes. Thanks for noticing. Levente Levente -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Progress Report] Zinc HTTP Components
response := ZnHttp new url: 'http://www.foo.com'; userAgent: 'FakeAgent'; cookieAt: 'something' put: '123'; parameterAt: 'q' put: 'smalltalk'; onFailure: [ :error | self inform: 'failed' ]; onProgress: [ :status | ... ]; get A bit like Gofer I guess... Yeah, the pattern is always the same :-) Seaside rendering, Gofer loading, Magritte description, ... It certainly looks cool, the code above. I'll have to think a little bit about that approach. The idea is that reasonably complex scenarios can be written as a single expression. How should such an object handle wrong use of the API ? What if I don't specify an url, do the get before setting the cookie, ... It feels as if there will be little feedback in terms of errors, no ? If you forget to specify an URL you'll likely get an exception at some (later) point. If you forget or do something after #get, #put, #delete, #head, ... it has no effect. Also you don't get the result, which is returned from these methods. In my opinion the missing feedback is not a problem in practice, people just have to remember to do the action last. Lukas -- Lukas Renggli www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Base64MimeConverterTest#testOnByteArray raise an error
ByteArray base64Encoded is no longer defined in Pharo 1.2, but used in the test Base64MimeConverterTest#testOnByteArray. It raise a DNU message. I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3027q=base64Encodedcolspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Pharo-users] [ANN] Pharo-1.1.1-dev10.09.1
Great! Doru On 1 Oct 2010, at 09:55, Mariano Martinez Peck wrote: Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo 1.1 but based on PharoCore 1.1.1. The versions of the external packages is the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has integrated some fixes and the support for CogVM. This means that Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For CogVM we recommend to use the last binaries that can be found in http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ This CogVM version fixes the problem with Objects as methods, and thus, all the #run:with:with are working. This means that tools like TestCoverage and AutoTest are working correctly with CogVM. The link to the image is: https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip Cheers Mariano ___ Pharo-users mailing list pharo-us...@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- www.tudorgirba.com Being happy is a matter of choice. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
On 1 October 2010 15:47, Stéphane Ducasse stephane.duca...@inria.fr wrote: Igor Can you have a look because right now in 12174 I cannot do any update anymore so - either we fix it now or we have to rollbakc to 12161. I will take a look Thanks. On Oct 1, 2010, at 12:49 PM, Igor Stasenko wrote: 2010/10/1 Levente Uzonyi le...@elte.hu: On Fri, 1 Oct 2010, Igor Stasenko wrote: On 1 October 2010 12:06, Levente Uzonyi le...@elte.hu wrote: On Fri, 1 Oct 2010, Marcus Denker wrote: Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload If you didn't fix the migration code, then WeakFinalizationRegistry is still in the system. Details here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/154009.html You mean this not work: Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. should be Smalltalk forgetClass: WeakFinalizationRegistry logged: false. right? Yes. Thanks for noticing. Levente Levente -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
Igor I was thinking to rollback now because we cannot do anything. Is is ok for you? And after we can include everything. Stef On Oct 1, 2010, at 3:08 PM, Igor Stasenko wrote: On 1 October 2010 15:47, Stéphane Ducasse stephane.duca...@inria.fr wrote: Igor Can you have a look because right now in 12174 I cannot do any update anymore so - either we fix it now or we have to rollbakc to 12161. I will take a look Thanks. On Oct 1, 2010, at 12:49 PM, Igor Stasenko wrote: 2010/10/1 Levente Uzonyi le...@elte.hu: On Fri, 1 Oct 2010, Igor Stasenko wrote: On 1 October 2010 12:06, Levente Uzonyi le...@elte.hu wrote: On Fri, 1 Oct 2010, Marcus Denker wrote: Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload If you didn't fix the migration code, then WeakFinalizationRegistry is still in the system. Details here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/154009.html You mean this not work: Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. should be Smalltalk forgetClass: WeakFinalizationRegistry logged: false. right? Yes. Thanks for noticing. Levente Levente -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] we will rollback until 12160
Hi guys sorry for the mess but the weakarray changes are putting the system on his knees. :) we cannot merge anymore. So I suggest that we rollback until 12160 and let igor happily fix it. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] XMLRPC project on Squeaksource is MIT
Hi Guys: Attached the agreement of the authors of current XMLRPC code on Squeaksource to make it MIT. Thanks Markus and Christian. -- From Markus -- From: Markus Fritsche fritsche.mar...@googlemail.com Date: 2010/10/1 Subject: Re: About the XMLRPC project on Squeaksource To: Germán Arduino g...@arsol.net Hello Germán, as far as I am concerned, I am happy to release my code under MIT license. I hope it will be well adapted to recent developments happening around Smalltalk Pharo! Kind regards, Markus (aka maf) 2010/9/22 Germán Arduino g...@arsol.net Hi Markus, Christian, César: I asked previously about the xmlrpc code on Squeaksource of each one of you and all agreed on release it as public domain. I need now (sorry by the bothering) your agreement that all your code on this repo XMLRPC is MIT licensed. Then I will send your responses to the pharo list to the system keeps track on that. Thanks Again! Germán. -- From Christian -- 2010/9/22 Christian Langreiter ch...@langreiter.com: Hello Germán, I need now (sorry by the bothering) your agreement that all your code on this repo XMLRPC is MIT licensed. Then I will send your responses to the pharo list to the system keeps track on that. no objections from my side. Best regards, -- Chris ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
On 1 October 2010 16:15, Stéphane Ducasse stephane.duca...@inria.fr wrote: Igor I was thinking to rollback now because we cannot do anything. Is is ok for you? And after we can include everything. Sure, no problem. It should not behave like that. There could be some very little speed degradation, but not like you describing. I found that after update 12172-12174 a FinalizationDependents in WeakArray held 4 weak registries before, but after update it also holds a WeakIdentityKeyDictionary with 9387 elements. This is something from monticello cache, but it screwed somehow.. I were able to delete it from weakdependents,manually, like in this script: arr := (WeakArray classPool at: #FinalizationDependents ). arr withIndexDo: [:e :i | e class == WeakRegistry ifFalse: [ arr at: i put: nil ]] After that, everything vent back to normal. This dictionary comes from MCMethodDefinition Definitions class var. So you can simply do: MCMethodDefinition shutDown to stop CPU hogging. But i wonder, if this is just one-time issue, or it will repeat again, after update. During writing this, i found that you already rewinded update, so i was unable to check if it will start consuming CPU on new code loaded, or its just some tension between MC and my migration procedure, which can be healed by MCMethodDefinition shutDown. Stef On Oct 1, 2010, at 3:08 PM, Igor Stasenko wrote: On 1 October 2010 15:47, Stéphane Ducasse stephane.duca...@inria.fr wrote: Igor Can you have a look because right now in 12174 I cannot do any update anymore so - either we fix it now or we have to rollbakc to 12161. I will take a look Thanks. On Oct 1, 2010, at 12:49 PM, Igor Stasenko wrote: 2010/10/1 Levente Uzonyi le...@elte.hu: On Fri, 1 Oct 2010, Igor Stasenko wrote: On 1 October 2010 12:06, Levente Uzonyi le...@elte.hu wrote: On Fri, 1 Oct 2010, Marcus Denker wrote: Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload If you didn't fix the migration code, then WeakFinalizationRegistry is still in the system. Details here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/154009.html You mean this not work: Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. should be Smalltalk forgetClass: WeakFinalizationRegistry logged: false. right? Yes. Thanks for noticing. Levente Levente -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
I found the bug.. This was in WeakKeyDictionaryexpiredValuesDo: Please, try doing the same with this patch, and see if problem gone. See attachment. -- Best regards, Igor Stasenko AKA sig. WeakKeyDictionary-expiredValuesDo.st Description: Binary data ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
On Fri, 1 Oct 2010, Igor Stasenko wrote: On 1 October 2010 16:15, Stéphane Ducasse stephane.duca...@inria.fr wrote: Igor I was thinking to rollback now because we cannot do anything. Is is ok for you? And after we can include everything. Sure, no problem. It should not behave like that. There could be some very little speed degradation, but not like you describing. I found that after update 12172-12174 a FinalizationDependents in WeakArray held 4 weak registries before, but after update it also holds a WeakIdentityKeyDictionary with 9387 elements. This is something from monticello cache, but it screwed somehow.. I were able to delete it from weakdependents,manually, like in this script: arr := (WeakArray classPool at: #FinalizationDependents ). arr withIndexDo: [:e :i | e class == WeakRegistry ifFalse: [ arr at: i put: nil ]] After that, everything vent back to normal. This dictionary comes from MCMethodDefinition Definitions class var. So you can simply do: MCMethodDefinition shutDown to stop CPU hogging. But i wonder, if this is just one-time issue, or it will repeat again, after update. During writing this, i found that you already rewinded update, so i was unable to check if it will start consuming CPU on new code loaded, or its just some tension between MC and my migration procedure, which can be healed by MCMethodDefinition shutDown. IIRC the WeakKeyDictionary is Pharo doesn't work (doesn't free slots or so) if it's not registered to the finalization process, but Henrik will correct me if I'm wrong. Levente Stef On Oct 1, 2010, at 3:08 PM, Igor Stasenko wrote: On 1 October 2010 15:47, Stéphane Ducasse stephane.duca...@inria.fr wrote: Igor Can you have a look because right now in 12174 I cannot do any update anymore so - either we fix it now or we have to rollbakc to 12161. I will take a look Thanks. On Oct 1, 2010, at 12:49 PM, Igor Stasenko wrote: 2010/10/1 Levente Uzonyi le...@elte.hu: On Fri, 1 Oct 2010, Igor Stasenko wrote: On 1 October 2010 12:06, Levente Uzonyi le...@elte.hu wrote: On Fri, 1 Oct 2010, Marcus Denker wrote: Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload If you didn't fix the migration code, then WeakFinalizationRegistry is still in the system. Details here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/154009.html You mean this not work: Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. should be Smalltalk forgetClass: WeakFinalizationRegistry logged: false. right? Yes. Thanks for noticing. Levente Levente -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12161
12161 - - Issue 3003: handleDisabledKey: is missing in Editor and subclasses - Issue 2963: systemOrganizer fixes. Thanks German Leiva and James Foester Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
2010/10/1 Levente Uzonyi le...@elte.hu: On Fri, 1 Oct 2010, Igor Stasenko wrote: On 1 October 2010 16:15, Stéphane Ducasse stephane.duca...@inria.fr wrote: Igor I was thinking to rollback now because we cannot do anything. Is is ok for you? And after we can include everything. Sure, no problem. It should not behave like that. There could be some very little speed degradation, but not like you describing. I found that after update 12172-12174 a FinalizationDependents in WeakArray held 4 weak registries before, but after update it also holds a WeakIdentityKeyDictionary with 9387 elements. This is something from monticello cache, but it screwed somehow.. I were able to delete it from weakdependents,manually, like in this script: arr := (WeakArray classPool at: #FinalizationDependents ). arr withIndexDo: [:e :i | e class == WeakRegistry ifFalse: [ arr at: i put: nil ]] After that, everything vent back to normal. This dictionary comes from MCMethodDefinition Definitions class var. So you can simply do: MCMethodDefinition shutDown to stop CPU hogging. But i wonder, if this is just one-time issue, or it will repeat again, after update. During writing this, i found that you already rewinded update, so i was unable to check if it will start consuming CPU on new code loaded, or its just some tension between MC and my migration procedure, which can be healed by MCMethodDefinition shutDown. IIRC the WeakKeyDictionary is Pharo doesn't work (doesn't free slots or so) if it's not registered to the finalization process, but Henrik will correct me if I'm wrong. It marks associations whose keys became nil as expired ones (association key: association). So, then associations get reused when new entries added. But i tricked myself by using #allAssociationsDo: , which were wiping out associations, before sending #finalize to their values... so, no finalization were run. Somehow, this lead to blowing up an MC method definitions cache. Levente Stef On Oct 1, 2010, at 3:08 PM, Igor Stasenko wrote: On 1 October 2010 15:47, Stéphane Ducasse stephane.duca...@inria.fr wrote: Igor Can you have a look because right now in 12174 I cannot do any update anymore so - either we fix it now or we have to rollbakc to 12161. I will take a look Thanks. On Oct 1, 2010, at 12:49 PM, Igor Stasenko wrote: 2010/10/1 Levente Uzonyi le...@elte.hu: On Fri, 1 Oct 2010, Igor Stasenko wrote: On 1 October 2010 12:06, Levente Uzonyi le...@elte.hu wrote: On Fri, 1 Oct 2010, Marcus Denker wrote: Issue 3002: A new finalization code ready for integration in Pharo Issue 3026: after 12172, sync with repository and reload If you didn't fix the migration code, then WeakFinalizationRegistry is still in the system. Details here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-September/154009.html You mean this not work: Smalltalk forgetClass: #WeakFinalizationRegistry logged: false. should be Smalltalk forgetClass: WeakFinalizationRegistry logged: false. right? Yes. Thanks for noticing. Levente Levente -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project
[Pharo-project] Issue 3036: SUnit Refactoring
In the course of working through A Mentoring Course on Smalltalk, I applied some small refactorings to SUnit. Issue: http://code.google.com/p/pharo/issues/detail?id=3036 Fix in inbox: SUnit-SeanDeNigris.114 * TestCase now uses classsuiteClass instead of referencing the class name directly * TestSuite now uses #resultClass instead of referencing the class name directly Also, 114 is a merge of SUnit-StephaneDucasse.113 and SUnit-SeanDeNigris.106 (a package saved in my local cache). Should I upload SUnit-SeanDeNigris.106 also? Thanks. Sean -- View this message in context: http://forum.world.st/Issue-3036-SUnit-Refactoring-tp2914375p2914375.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12162
12162 - Issue 2713: Changelist deserves some fixes Issue 3030: Remove Explain... code (again) Issue 3023: change the initial windows position strategy Issue 3028: PluggableListMorphByItem getCurrentSelectionIndex access directly a non-initailized instance variable Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] ToolBuilderTeststestGetButtonSideEffects seems to be wrong
if you look at the code of ToolBuilderTeststestGetButtonSideEffects: testGetButtonSideEffects self makeButton. queries := IdentitySet new. self changed: #testSignalWithNoDiscernableEffect. self expectedButtonSideEffects do:[:sym| self assert: (queries includes: sym). queries remove: sym. ]. the variable queries is never fill in, therefore I don't understand how the assertion could pass. In pharo 1.2-12159 the test fail for the class MorphicToolBuilderTests for which 'expectedButtonSideEffects' return a non-empty collection (unlike ToolBuilderTests). I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3038 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Multiple finalizers per single object
I sort of disagree, in that it's neat to have a way for objects to be notified when other objects die, without that object necessarily having to know about all objects that may be interested in its death. (Like, in Leventes case which triggered their creation in the first place, objects which are weakly registered to one or more announcers) I don't really see the benefit in constraining an existing, flexible mechanic to only cover the common use case. If multiple finalizers are removed, at least so should ObjecttoFinalizeSend:to:with: (and potentially other spots, I haven't checked exactly) leaving Object finalize as the only place where finalization actions take place. (Which is where the actions Igor are talking about should be happening in the first place) Cheers, Henry On Sep 23, 2010, at 10:36 27PM, Chris Muller wrote: I agree that multiple finalizers per object seems unnecessary and, as you pointed out, potentially confusing, if not also conflicting. TSTTCPW seems appropriate in this case. On Thu, Sep 23, 2010 at 3:23 PM, Igor Stasenko siguc...@gmail.com wrote: Hello, i'd like to raise this subject once more, because i don't like it (or don't understand?). In all scenarios, where i met the need to use finalization, a single finalizer is sufficient. Moreover, there is always a single object who controls a weak reference, and it never leaks it out, to prevent the case, when some other object may obtain a strong reference on it, making it permanently held in object memory. Multiple different finalizers for single object, from design point of view, means that you having two different, not related frameworks, which using same object, and want to do something when it dies. A scenario, where its possible and userful, still don't comes into my mind. In contrary, whenever i see a use of finalizers, its in most cases about graceful control over external resource, such as: - file - socket - external memory and i really don't see how multiple finalizers per single resource could do any good. Suppose one finalizer closing a file handle, while another one flushing it buffer cache. Now, how you going to ensure, that one finalizer will execute first, before another one? And what if third framework comes into play and wants to add another finalizer on top of that, which should do something in the middle between flushing a cache and closing file handle? From the above, the only conclusion can be made: use a single finalizer, and put all logic operation ordering into it. And also, prevent leakage of object pointer (such as file handle) outside of your model, otherwise it may cause harm. That's why i think a current WeakRegistry model provoking bad design practices. I think a better behavior would be to raise an error, if something wants to register finalizer twice for a single object. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12163
12163 - - Issue 3035: Workspace(Object)doesNotUnderstand: #spawn:. Thanks mariano Martinez-Peck - Issue 3032: Memory consuption of Objects. Thanks mariano Martinez-Peck - Issue 3037: SpaceTally should use #instancesSizeInMemory. Thanks mariano Martinez-Peck ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Progress Report] Zinc HTTP Components
Hi everyone, On Oct 1, 2010, at 8:10 AM, Lukas Renggli wrote: Wow, very impressive. What I would like to see is some kind of high-level API for convenient access to all features. Something along response := ZnHttp new url: 'http://www.foo.com'; userAgent: 'FakeAgent'; cookieAt: 'something' put: '123'; parameterAt: 'q' put: 'smalltalk'; onFailure: [ :error | self inform: 'failed' ]; onProgress: [ :status | ... ]; get Lukas This is actually where I'd like to head with the client API. I had started my own HTTP client about 2 days before Sven announced Zinc, so it made more sense contribute to his project. My initial work was a subclass off of ProtocolClient and was kind of monolithic, so my first steps have been to make things mesh nicely with Zinc. My initial prototype before I started working on Zinc had a very similar API to your example, so my thoughts are definitely aimed for that direction. Matt ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12164
12164 - - Issue 3040: Launch change sorter in Pharo 12162 throws DNU. Thanks Luc Fabresse. - Issue 3020: Monticello uses a lot of Smalltalk instead of Smalltalk globals. Thanks Nicolas Paez Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
Oh crap.. the problem is not in that. MC produces huge weak-key dictionary during updates for instance 12159 - 12162 produces dictionary with 14k entries, which sits in #FinalizationDependents array and scanned after each GC. And during scanning, its using block closures (and each push of block closure consuming memory), so it big enough to trigger another GC. And its self-supporting process of wasting CPU cycles just for nothing... Here some numbers: (note, i din't installed new finalization code yet) MCMethodDefinition cachedDefinitions size 14987 [MCMethodDefinition cachedDefinitions finalizeValues ] timeToRun 10 so, it spends 10 ms dueing each GC cycle for scanning it. So, the quest is to avoid using block closures during scanning it, so it won't produce garbage. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12165
12165 - - Issue 3010: Create button of debugger does not appear when doing step into and step over. Thanks Hernan Wilkinson and Luc Fabresse and Jean-Baptiste Arnaud. - Issue 3011: Create button fails when the doesNotUnderstand: context is not selected. Thanks Hernan Wilkinson and Luc Fabresse and Jean-Baptiste Arnaud. - Issue 965:Messages send but not implemented. Thanks Luc Fabresse Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [update 1.2] #12161 - #12172
Here what happens: Original method WeakKeyDictionaryfinalizeValues WeakKeyDictionaryfinalizeValues Clear all associations with nil keys array do:[:assoc| 1 to: array size do:[:i | | assoc | assoc := array at: i. assoc ifNotNil:[ assoc expire ifTrue:[ expired := expired + 1. tally := tally - 1. ]. ]. ]. And i noticed that after recompilation of this method, it starts spending much more time to scan 14k entries: [MCMethodDefinition cachedDefinitions finalizeValues ] timeToRun 167 (my guess that this method was never recompiled with new Eliot's closures). Now, if i change it to: finalizeValues Clear all associations with nil keys 1 to: array size do:[:i | | assoc | assoc := array at: i. array do:[:assoc| assoc ifNotNil:[ assoc expire ifTrue:[ expired := expired + 1. tally := tally - 1. ]. ]. ]. so, #to:do: is inlined by compiler, then numbers is much better: [MCMethodDefinition cachedDefinitions finalizeValues ] timeToRun 4 Just try it yourself, if you not believe. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.2] #12166
12166 - Issue 2943: SUnit 4. Thanks Jannik Laval and Nicolas Anquetil ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
I uploaded new changesets to http://code.google.com/p/pharo/issues/detail?id=3002 I tested applying them in Pharo-Core-#12159 and then updating an image after that. After update: MCMethodDefinition cachedDefinitions size is 18668 But image don't feels slow. As a side note, i recommend to review the MC caching mechanism towards avoiding putting so much load on finalization process (such as scanning 18k entries to find dead objects). This is actually the purpose of new finalization scheme: - it allows to avoid scanning whole weak dictionary in order to get rid of expired associations. I'm already implemented a variant of self-cleaning weak dictionary for Magma, which using new finalization scheme, and avoids scanning huge number of entries to discover few of them, which became garbage. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Issue 3044: Method editor failing
*http://code.google.com/p/pharo/issues/detail?id=3044* *Steps to reproduce:* 1. Create a method 2. Declare a temp (i.e. myVariable) 3. Write some code sending a message to a non-existing temp with a name similar to the one you declared (i.e. myVar) 4. Try to save. You should get a suggestion to change myVar - myVariable. 5. Accept the suggestion 6. Your code will be modify in a wrong way: intead of getting myVariable you will get myVariableiable Saludos! Nico. blog: nicopaez.wordpress.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Issue 3045: DOCUMENTATION: Added comment to RBMethodNodemethodComments
Added comment to RBMethodNodemethodComments indicating that what gets returned is a collection of index intervals, not the actual comment strings http://code.google.com/p/pharo/issues/detail?id=3045 Fix in Inbox: AST-Core-SeanDeNigris.80 -- View this message in context: http://forum.world.st/Issue-3045-DOCUMENTATION-Added-comment-to-RBMethodNode-methodComments-tp2932056p2932056.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Issue 3046: BUG: LineMorph classfrom:to:color:width: returns a PolygonMorph
http://code.google.com/p/pharo/issues/detail?id=3046 Fix in inbox: Morphic-SeanDeNigris.625 LineMorph classfrom:to:color:width: changed to return a LineMorph Sean -- View this message in context: http://forum.world.st/Issue-3046-BUG-LineMorph-class-from-to-color-width-returns-a-PolygonMorph-tp2933188p2933188.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Issue 3047: REFACTOR: Added intention revealing helper method to AppRegistry classregister:
http://code.google.com/p/pharo/issues/detail?id=3047 Old: register: aProviderClass ... default := nil. so it'll ask for a new default... ... New: ... self askForNewDefaultOnNextRequest. ... Fix in inbox: System-Applications-SeanDeNigris.15 -- View this message in context: http://forum.world.st/Issue-3047-REFACTOR-Added-intention-revealing-helper-method-to-AppRegistry-class-register-tp2934490p2934490.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
On Fri, 1 Oct 2010, Igor Stasenko wrote: I uploaded new changesets to http://code.google.com/p/pharo/issues/detail?id=3002 I tested applying them in Pharo-Core-#12159 and then updating an image after that. After update: MCMethodDefinition cachedDefinitions size is 18668 But image don't feels slow. As a side note, i recommend to review the MC caching mechanism towards avoiding putting so much load on finalization process (such as scanning 18k entries to find dead objects). This is actually the purpose of new finalization scheme: - it allows to avoid scanning whole weak dictionary in order to get rid of expired associations. WeakKeyDictionaries shouldn't be added to the finalization process at all. In the current case there's no finalization action at all, so it's totally pointless IMO. And these dictionaries are not thread-safe, so bad things can happen if they are registered with the finalization process. I'm already implemented a variant of self-cleaning weak dictionary for Magma, which using new finalization scheme, and avoids scanning huge number of entries to discover few of them, which became garbage. Squeak's WeakKeyDictionaries are self cleaning, though the there's no guarantee that finalization action is performed when the key is GC'd. Levente -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Metacello] Re: loading groups with metacello
Mariano Martinez Peck wrote:
On Fri, Oct 1, 2010 at 2:16 PM, Veronica Isabel Uquillas Gomez
vuqui...@vub.ac.be mailto:vuqui...@vub.ac.be wrote:
Hi Mariano,
You already saw my problem.
With this you can check what is happening: (ConfigurationOfGlamour
project version: 'default') record: #('Core' 'Tests' 'Extras')
I don't understand why this loads Grease for example. Dale any idea?
I checked loadDirective but I didn't understand.
Cheers
Mariano
all the pre-requisites are being loaded and not only the groups.
Regards, Veronica ___
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
mailto:Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Okay, Here's the printString of the loadDirectives:
linear load :
linear load : default [ConfigurationOfGlamour]
load : ConfigurationOfGrease
linear load : default [ConfigurationOfGlamour]
load : ConfigurationOfMondrian
atomic load : default [ConfigurationOfGlamour]
load : Glamour-Announcements
load : Glamour-Helpers
load : Glamour-Core
load : Glamour-Presentations
load : Glamour-Browsers
load : Glamour-Tests-Core
load : Glamour-Morphic-Theme
load : Glamour-Examples
load : Glamour-Tools
linear load : default [ConfigurationOfMondrian]
load : ConfigurationOfHealthReportProducer
linear load : default [ConfigurationOfMondrian]
load : ConfigurationOfProfStef
atomic load : default [ConfigurationOfMondrian]
linear load : 1.3 [ConfigurationOfProfStef]
load : ConfigurationOfShout
linear load : 1.3 [ConfigurationOfProfStef]
linear load : 1.1.1 [ConfigurationOfShout]
load : Shout-lr.90
load : ShoutWorkspace.pharo-1-1-SeanDeNigris.6
load : ProfStef-Core-LaurentLaffont.11
load : ProfStefBrowser-LaurentLaffont.26
load : ProfStef-Tests-LaurentLaffont.8
load : ProfStef-Help-LaurentLaffont.1
load : Mondrian
load : CollectionExtensions
atomic load : 0.1-baseline [ConfigurationOfHealthReportProducer]
load : HealthReportProducer
load : Glamour-Scripting
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : ConfigurationOfRefactoringBrowser
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : Grease-Core-lr.37
load : Grease-Pharo-Core-jok.18
linear load : 1.3 [ConfigurationOfRefactoringBrowser]
load : AST-Core-lr.73
load : Refactoring-Core-lr.136
load : Grease-Slime-jok.5
load : Magritte-Model
load : Magritte-Morph
load : Glamour-Morphic-Renderer
load : Glamour-Tests-Morphic
and here's the section related to Grease (very end of directives):
load : Glamour-Scripting
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : ConfigurationOfRefactoringBrowser
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : Grease-Core-lr.37
load : Grease-Pharo-Core-jok.18
linear load : 1.3 [ConfigurationOfRefactoringBrowser]
load : AST-Core-lr.73
load : Refactoring-Core-lr.136
load : Grease-Slime-jok.5
load : Magritte-Model
load : Magritte-Morph
load : Glamour-Morphic-Renderer
load : Glamour-Tests-Morphic
The load directive is in load order which is reverse prerequisite
order. In other words, the clue for why Grease is loaded lies in the
directives _following_ the Grease directives...
In this case Magritte-Model immediately follows the loading of Grease
implying that Magritte-Model, requires Grease (and then confirmed by
looking at the configuration)
Reading on: Magritte-Morph requires Magritte-Model,
Glamour-Morphic-Renderer requires Magritte-Morph and
Glamour-Tests-Morphic requires Glamour-Morphic-Renderer.
From the configuration, Glamour-Tests-Morphic is a member of Tests and
Tests is being loaded (or recorded in this case).
Does this help?
Note that ConfigurationOfGlamour is not using ConfigurationOfMagritte2.
I think that is because of problems with earlier versions of the
CofigurationOfMagritte2, when seaside30 was loaded when you tried to
load Magritte. The latest ConfigurationOfMagritte2 doesn't have that
problem anymore, Glamour could be using ConfigurationOfMagritte2 now.
Dale
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
On 1 October 2010 20:05, Levente Uzonyi le...@elte.hu wrote: On Fri, 1 Oct 2010, Igor Stasenko wrote: I uploaded new changesets to http://code.google.com/p/pharo/issues/detail?id=3002 I tested applying them in Pharo-Core-#12159 and then updating an image after that. After update: MCMethodDefinition cachedDefinitions size is 18668 But image don't feels slow. As a side note, i recommend to review the MC caching mechanism towards avoiding putting so much load on finalization process (such as scanning 18k entries to find dead objects). This is actually the purpose of new finalization scheme: - it allows to avoid scanning whole weak dictionary in order to get rid of expired associations. WeakKeyDictionaries shouldn't be added to the finalization process at all. In the current case there's no finalization action at all, so it's totally pointless IMO. And these dictionaries are not thread-safe, so bad things can happen if they are registered with the finalization process. well..then we probably should fix this: MCMethodDefinitioncachedDefinitions Definitions ifNil: [Definitions := WeakIdentityKeyDictionary new. WeakArray addWeakDependent: Definitions]. ^ Definitions I'm already implemented a variant of self-cleaning weak dictionary for Magma, which using new finalization scheme, and avoids scanning huge number of entries to discover few of them, which became garbage. Squeak's WeakKeyDictionaries are self cleaning, though the there's no guarantee that finalization action is performed when the key is GC'd. it depends how badly you need to keep things clean as soon as its possible :) It is really not necessary to add cachedDefinitions to weakdependets and check them each time after GC. In case of MC, i think a dead-keys cleanup should be triggered only after package loading/unloading, but not during each GC. Levente -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Base64MimeConverterTest#testOnByteArray raise an error
The problem is that when the method base64Encoded was moved, packages Collections and Network were marked as dirty but not the package MimeConverter so the new version was not sent to the repository. -- Pavel 2010/10/1 Cyrille Delaunay cy.delau...@gmail.com ByteArray base64Encoded is no longer defined in Pharo 1.2, but used in the test Base64MimeConverterTest#testOnByteArray. It raise a DNU message. I opened an Issue: http://code.google.com/p/pharo/issues/detail?id=3027q=base64Encodedcolspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
Here the simple fix for it. -- Best regards, Igor Stasenko AKA sig. mc-cache-fix.1.cs Description: Binary data ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1
Great, gave it a try, loaded my app I was developing, and the page rendering speed in Seaside has dropped from 15-20 msecs to 5-10 :-). And all my tests are green! keep them coming! Regards, Bart 2010/10/1 Mariano Martinez Peck marianop...@gmail.com Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo 1.1 but based on PharoCore 1.1.1. The versions of the external packages is the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has integrated some fixes and the support for CogVM. This means that Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For CogVM we recommend to use the last binaries that can be found in http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ This CogVM version fixes the problem with Objects as methods, and thus, all the #run:with:with are working. This means that tools like TestCoverage and AutoTest are working correctly with CogVM. The link to the image is: https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: Help is now able to define where subbooks are placed
Yes, this is very useful for me. Thank you Enrico and Thorsten! --Hannes On 10/1/10, Enrico Spinielli enrico.spinie...@googlemail.com wrote: Torsten, all thanks go to you for having thought/designed/implemented _and_ for following HelpSystem up! Well done Bye Enrico On Fri, Oct 1, 2010 at 00:19, Torsten Bergmann asta...@gmx.de wrote: 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 -- Enrico Spinielli Do Androids dream of electric sheep?— Philip K. Dick Hear and forget; see and remember;do and understand.—Mitchel Resnick ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Another fixes to finalization (was Re: [update 1.2] #12161 - #12172)
I just tried to update image with old cache: [ Utilities updateFromServer] timeToRun 397707 and without it: [ Utilities updateFromServer] timeToRun 347708 397707 / 347708 asFloat 1.143795943722894 so, roughly 14% of CPU time (about 50 seconds) wasted on scanning the cache at each GC. Of course this measure a bit dirty, because there a network activity involved . On 1 October 2010 20:33, Igor Stasenko siguc...@gmail.com wrote: Here the simple fix for it. -- Best regards, Igor Stasenko AKA sig. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] haltOnce and haltOnCount
ah, ok, I imagine that but what it was a bit of a surprise for me is that it is implemented in Object... I mean, I know that halt is also implemented in Object and it is the natural place to implement those messages, but if we want to build a modular system, messages like halt, error, etc should be removed from Object and seeing that Object is growing in its responsibilities with these messages I think that goes against that path... of course, if you decided that the trade off deserves it, fine by me... I was thinking that halt for example could be implemented in MethodContext (or ContextPart) so you can write something like thisContext halt and not couple Object with Halt (of course we would be coupling MethodContext with Halt, but it is a smaller coupling)... or just remove halt as a message and force everybody to just write Halt signal of Halt signalOnce etc. I mean, why Object implements halt? I know it is handy to do self halt but also as handy as Halt signal... the only reason I see to implement halt in Object is the possibility for any subclass to override that message, but I haven't seen that in my years of smalltalker... Anyway, just a late's Friday thought :-) PS: A #haltIf: aBlock message would be handy too :-) On Fri, Oct 1, 2010 at 8:53 AM, Stéphane Ducasse stephane.duca...@inria.frwrote: + 1 really really important On Sep 30, 2010, at 11:38 PM, Alexandre Bergel wrote: 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.wilkin...@10pines.com site: http://www.10Pines.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- *Hernán Wilkinson Agile Software Development, Teaching Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkin...@10pines.com site: http://www.10Pines.com http://www.10pines.com/* ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] haltOnce and haltOnCount
There is already an issue about removing that responsibility from Object. I made a little enhancement some months ago (it was the first issue I fixed :P) but it never got integrated because it was not urgent. http://code.google.com/p/pharo/issues/detail?id=2394q=haltcolspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty Cheers! 2010/10/1 Hernan Wilkinson hernan.wilkin...@10pines.com ah, ok, I imagine that but what it was a bit of a surprise for me is that it is implemented in Object... I mean, I know that halt is also implemented in Object and it is the natural place to implement those messages, but if we want to build a modular system, messages like halt, error, etc should be removed from Object and seeing that Object is growing in its responsibilities with these messages I think that goes against that path... of course, if you decided that the trade off deserves it, fine by me... I was thinking that halt for example could be implemented in MethodContext (or ContextPart) so you can write something like thisContext halt and not couple Object with Halt (of course we would be coupling MethodContext with Halt, but it is a smaller coupling)... or just remove halt as a message and force everybody to just write Halt signal of Halt signalOnce etc. I mean, why Object implements halt? I know it is handy to do self halt but also as handy as Halt signal... the only reason I see to implement halt in Object is the possibility for any subclass to override that message, but I haven't seen that in my years of smalltalker... Anyway, just a late's Friday thought :-) PS: A #haltIf: aBlock message would be handy too :-) On Fri, Oct 1, 2010 at 8:53 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: + 1 really really important On Sep 30, 2010, at 11:38 PM, Alexandre Bergel wrote: 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.wilkin...@10pines.com site: http://www.10Pines.com ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- *Hernán Wilkinson Agile Software Development, Teaching Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkin...@10pines.com site: http://www.10Pines.com http://www.10pines.com/* ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] haltOnce and haltOnCount
On Oct 1, 2010, at 8:08 PM, Hernan Wilkinson wrote: PS: A #haltIf: aBlock message would be handy too :-) already there: 1 haltIf: [12]. 1 haltIf: [:rec | rec isInteger]. 1 haltIf: (12). 1 haltIf: #doIt especially putting a symbol is very useful. e.g. you can out the selector of the test and then even put a haltIf: into system methods called all the time. (e.g. collections). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] haltOnce and haltOnCount
cool! I didn't see it :-) 2010/10/1 Marcus Denker marcus.den...@inria.fr On Oct 1, 2010, at 8:08 PM, Hernan Wilkinson wrote: PS: A #haltIf: aBlock message would be handy too :-) already there: 1 haltIf: [12]. 1 haltIf: [:rec | rec isInteger]. 1 haltIf: (12). 1 haltIf: #doIt especially putting a symbol is very useful. e.g. you can out the selector of the test and then even put a haltIf: into system methods called all the time. (e.g. collections). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- *Hernán Wilkinson Agile Software Development, Teaching Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkin...@10pines.com site: http://www.10Pines.com http://www.10pines.com/* ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1
2010/10/1 Bart Gauquie bart.gauq...@gmail.com Great, gave it a try, loaded my app I was developing, and the page rendering speed in Seaside has dropped from 15-20 msecs to 5-10 :-). With the standard SqueakVM or with CogVM? And all my tests are green! keep them coming! :) Regards, Bart 2010/10/1 Mariano Martinez Peck marianop...@gmail.com Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo 1.1 but based on PharoCore 1.1.1. The versions of the external packages is the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has integrated some fixes and the support for CogVM. This means that Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For CogVM we recommend to use the last binaries that can be found in http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ This CogVM version fixes the problem with Objects as methods, and thus, all the #run:with:with are working. This means that tools like TestCoverage and AutoTest are working correctly with CogVM. The link to the image is: https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1
2010/10/1 Eliot Miranda eliot.mira...@gmail.com Hi Mariano, 2010/10/1 Mariano Martinez Peck marianop...@gmail.com Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo 1.1 but based on PharoCore 1.1.1. The versions of the external packages is the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has integrated some fixes and the support for CogVM. This means that Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For CogVM we recommend to use the last binaries that can be found in http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ This CogVM version fixes the problem with Objects as methods, and thus, all the #run:with:with are working. This means that tools like TestCoverage and AutoTest are working correctly with CogVM. WHile some simple things now work there's definitely at least one bug remaining (perform:withArguments: doesn't work for objects-as-methods) and Nicolas tried a more demanding test (the coverage test from XTreams) and found problems; see http://lists.gforge.inria.fr/pipermail/pharo-project/2010-September/033230.html. I'll be releasing a new VM that will fix the perform issue, but it remains to be seen whether the bugs Nicolas as found are fixed by this. So while .33 is better Cog still doesn't support objects-as-method correctly. Thanks Eliot for making this clear. Just let us know when this is fixed :) Cheers Mariano HTH Eliot The link to the image is: https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Metacello] Re: loading groups with metacello
On Fri, Oct 1, 2010 at 7:13 PM, Dale Henrichs dhenr...@vmware.com wrote:
Mariano Martinez Peck wrote:
On Fri, Oct 1, 2010 at 2:16 PM, Veronica Isabel Uquillas Gomez
vuqui...@vub.ac.be mailto:vuqui...@vub.ac.be wrote:
Hi Mariano,
You already saw my problem.
With this you can check what is happening: (ConfigurationOfGlamour
project version: 'default') record: #('Core' 'Tests' 'Extras')
I don't understand why this loads Grease for example. Dale any idea?
I checked loadDirective but I didn't understand.
Cheers
Mariano
all the pre-requisites are being loaded and not only the groups.
Regards, Veronica ___
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr mailto:
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Okay, Here's the printString of the loadDirectives:
linear load :
linear load : default [ConfigurationOfGlamour]
load : ConfigurationOfGrease
linear load : default [ConfigurationOfGlamour]
load : ConfigurationOfMondrian
atomic load : default [ConfigurationOfGlamour]
load : Glamour-Announcements
load : Glamour-Helpers
load : Glamour-Core
load : Glamour-Presentations
load : Glamour-Browsers
load : Glamour-Tests-Core
load : Glamour-Morphic-Theme
load : Glamour-Examples
load : Glamour-Tools
linear load : default [ConfigurationOfMondrian]
load : ConfigurationOfHealthReportProducer
linear load : default [ConfigurationOfMondrian]
load : ConfigurationOfProfStef
atomic load : default [ConfigurationOfMondrian]
linear load : 1.3 [ConfigurationOfProfStef]
load : ConfigurationOfShout
linear load : 1.3 [ConfigurationOfProfStef]
linear load : 1.1.1 [ConfigurationOfShout]
load : Shout-lr.90
load : ShoutWorkspace.pharo-1-1-SeanDeNigris.6
load : ProfStef-Core-LaurentLaffont.11
load : ProfStefBrowser-LaurentLaffont.26
load : ProfStef-Tests-LaurentLaffont.8
load : ProfStef-Help-LaurentLaffont.1
load : Mondrian
load : CollectionExtensions
atomic load : 0.1-baseline [ConfigurationOfHealthReportProducer]
load : HealthReportProducer
load : Glamour-Scripting
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : ConfigurationOfRefactoringBrowser
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : Grease-Core-lr.37
load : Grease-Pharo-Core-jok.18
linear load : 1.3 [ConfigurationOfRefactoringBrowser]
load : AST-Core-lr.73
load : Refactoring-Core-lr.136
load : Grease-Slime-jok.5
load : Magritte-Model
load : Magritte-Morph
load : Glamour-Morphic-Renderer
load : Glamour-Tests-Morphic
and here's the section related to Grease (very end of directives):
load : Glamour-Scripting
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : ConfigurationOfRefactoringBrowser
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : Grease-Core-lr.37
load : Grease-Pharo-Core-jok.18
linear load : 1.3 [ConfigurationOfRefactoringBrowser]
load : AST-Core-lr.73
load : Refactoring-Core-lr.136
load : Grease-Slime-jok.5
load : Magritte-Model
load : Magritte-Morph
load : Glamour-Morphic-Renderer
load : Glamour-Tests-Morphic
The load directive is in load order which is reverse prerequisite
order. In other words, the clue for why Grease is loaded lies in the
directives _following_ the Grease directives...
a I was looking BEFORE, not after hehehe.. what an idiot I am :)
In this case Magritte-Model immediately follows the loading of Grease
implying that Magritte-Model, requires Grease (and then confirmed by looking
at the configuration)
Reading on: Magritte-Morph requires Magritte-Model,
Glamour-Morphic-Renderer requires Magritte-Morph and Glamour-Tests-Morphic
requires Glamour-Morphic-Renderer.
From the configuration, Glamour-Tests-Morphic is a member of Tests and
Tests is being loaded (or recorded in this case).
Does this help?
Completly understood :)
Note that ConfigurationOfGlamour is not using ConfigurationOfMagritte2. I
think that is because of problems with earlier versions of the
CofigurationOfMagritte2, when seaside30 was loaded when you tried to load
Magritte. The latest ConfigurationOfMagritte2 doesn't have that problem
anymore, Glamour could be using ConfigurationOfMagritte2 now.
Dale
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Introducing smallUML: a little project to help us document :)
Carla F. Griggio wrote: OK, although I tried to use what I separated in the Minimal Connectors package and there are still some things missing to be able to use it independently. So (although we're already talking about that here XD) we shouldn't announce that yet. Any progress with Minimal Connectors? I would love to use it in several of the projects I'm working on. Thanks. Sean -- View this message in context: http://forum.world.st/Introducing-smallUML-a-little-project-to-help-us-document-tp2331341p2937340.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [Metacello] Re: loading groups with metacello
Mariano Martinez Peck wrote:
On Fri, Oct 1, 2010 at 7:13 PM, Dale Henrichs dhenr...@vmware.com
mailto:dhenr...@vmware.com wrote:
Mariano Martinez Peck wrote:
On Fri, Oct 1, 2010 at 2:16 PM, Veronica Isabel Uquillas Gomez
vuqui...@vub.ac.be mailto:vuqui...@vub.ac.be
mailto:vuqui...@vub.ac.be mailto:vuqui...@vub.ac.be wrote:
Hi Mariano,
You already saw my problem.
With this you can check what is happening: (ConfigurationOfGlamour
project version: 'default') record: #('Core' 'Tests' 'Extras')
I don't understand why this loads Grease for example. Dale any idea?
I checked loadDirective but I didn't understand.
Cheers
Mariano
all the pre-requisites are being loaded and not only the groups.
Regards, Veronica
___ Pharo-project
mailing list Pharo-project@lists.gforge.inria.fr
mailto:Pharo-project@lists.gforge.inria.fr
mailto:Pharo-project@lists.gforge.inria.fr
mailto:Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Okay, Here's the printString of the loadDirectives:
linear load :
linear load : default [ConfigurationOfGlamour]
load : ConfigurationOfGrease
linear load : default [ConfigurationOfGlamour]
load : ConfigurationOfMondrian
atomic load : default [ConfigurationOfGlamour]
load : Glamour-Announcements
load : Glamour-Helpers
load : Glamour-Core
load : Glamour-Presentations
load : Glamour-Browsers
load : Glamour-Tests-Core
load : Glamour-Morphic-Theme
load : Glamour-Examples
load : Glamour-Tools
linear load : default [ConfigurationOfMondrian]
load : ConfigurationOfHealthReportProducer
linear load : default [ConfigurationOfMondrian]
load : ConfigurationOfProfStef
atomic load : default [ConfigurationOfMondrian]
linear load : 1.3 [ConfigurationOfProfStef]
load : ConfigurationOfShout
linear load : 1.3 [ConfigurationOfProfStef]
linear load : 1.1.1 [ConfigurationOfShout]
load : Shout-lr.90
load : ShoutWorkspace.pharo-1-1-SeanDeNigris.6
load : ProfStef-Core-LaurentLaffont.11
load : ProfStefBrowser-LaurentLaffont.26
load : ProfStef-Tests-LaurentLaffont.8
load : ProfStef-Help-LaurentLaffont.1
load : Mondrian
load : CollectionExtensions
atomic load : 0.1-baseline [ConfigurationOfHealthReportProducer]
load : HealthReportProducer
load : Glamour-Scripting
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : ConfigurationOfRefactoringBrowser
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : Grease-Core-lr.37
load : Grease-Pharo-Core-jok.18
linear load : 1.3 [ConfigurationOfRefactoringBrowser]
load : AST-Core-lr.73
load : Refactoring-Core-lr.136
load : Grease-Slime-jok.5
load : Magritte-Model
load : Magritte-Morph
load : Glamour-Morphic-Renderer
load : Glamour-Tests-Morphic
and here's the section related to Grease (very end of directives):
load : Glamour-Scripting
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : ConfigurationOfRefactoringBrowser
linear load : 1.0-alpha9.1 [ConfigurationOfGrease]
load : Grease-Core-lr.37
load : Grease-Pharo-Core-jok.18
linear load : 1.3 [ConfigurationOfRefactoringBrowser]
load : AST-Core-lr.73
load : Refactoring-Core-lr.136
load : Grease-Slime-jok.5
load : Magritte-Model
load : Magritte-Morph
load : Glamour-Morphic-Renderer
load : Glamour-Tests-Morphic
The load directive is in load order which is reverse prerequisite
order. In other words, the clue for why Grease is loaded lies in
the directives _following_ the Grease directives...
a I was looking BEFORE, not after hehehe.. what an idiot I am :)
Not necessarily ... I didn't figure that out until after I'd
understood why Grease was being loaded ... haha!
Dale
___
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Introducing smallUML: a little project to help us document :)
I've just arrived home this week, so I made no progress over the last two weeks. But at ESUG I talked a little with Fernando Olivero and made me realize that I'm very close to finish the Minimal Connectors package, at least the minimal minimal connectors XD I'll let you know :) Let me know what are your projects about and how you would use this :O On Fri, Oct 1, 2010 at 4:19 PM, Sean P. DeNigris s...@clipperadams.comwrote: Carla F. Griggio wrote: OK, although I tried to use what I separated in the Minimal Connectors package and there are still some things missing to be able to use it independently. So (although we're already talking about that here XD) we shouldn't announce that yet. Any progress with Minimal Connectors? I would love to use it in several of the projects I'm working on. Thanks. Sean -- View this message in context: http://forum.world.st/Introducing-smallUML-a-little-project-to-help-us-document-tp2331341p2937340.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Chilean mailing list
Hi All! We've just create a mailing list for discussing about Pharo/Smalltalk in Chile. pharo-ch...@googlegroups.com http://groups.google.com/group/pharo-chile Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Chilean mailing list
On Fri, Oct 1, 2010 at 10:18 PM, Alexandre Bergel alexan...@bergel.euwrote: Hi All! We've just create a mailing list for discussing about Pharo/Smalltalk in Chile. pharo-ch...@googlegroups.com http://groups.google.com/group/pharo-chile Does it make sense ? I ask because maybe with clubSmalltalk (in Spanish) is enough. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image
On Fri, Oct 1, 2010 at 8:26 AM, Igor Stasenko siguc...@gmail.com wrote: On 1 October 2010 08:48, Mariano Martinez Peck marianop...@gmail.com wrote: On Thu, Sep 30, 2010 at 11:07 PM, Johan Fabry jfa...@dcc.uchile.cl wrote: Hi all, I am planning to put online a minimal image that contains AspectMaps, with some models pre-loaded. Two questions: - Is there an easy way to strip this image of dev tools et cetera? Not really. The easiest way is to have a Configuration of Metacello that takes care of loading all your code with all your dependencies. Then, take a PharoCore and load your code there. In addition, you may want to evaluate ScriptLoader cleanUpForProduction at the end. Check the method to see what it does. - How can I make it so that I can distribute it without the changes file? (Right now the image complains of a missing changes file if it is not there ...) I am aware of Smalltalk abandonSources to avoid using .sources. You won't see things like the temp names, and stuff will be decompiled instead. With a little effort, you can embed source code into method trailers. Then you won't need .sources nor .chanes to see the real source instead of decompiling it. But you will loose method stamps. I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, if I will improve performance since I don't need to fetch a .sources file. what would be awesome is if we can have both, this is: for the dev image, I would like to have the sources in the image, but not for PharoCore. Or maybe also in PharoCore but to be sure to be able to remove them, and use .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction or similar. thoughts? For the .changes you can start the image without them, there will raise a popup at the beginning. The problem is if you then do sometthing that should be written there. Not sure here... yeah. cheers Mariano Thanks in advance! -- Johan Fabry jfa...@dcc.uchile.cl - http://dcc.uchile.cl/~jfabryhttp://dcc.uchile.cl/%7Ejfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile ___ Pharo-users mailing list pharo-us...@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users ___ Pharo-users mailing list pharo-us...@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- Best regards, Igor Stasenko AKA sig. ___ Pharo-users mailing list pharo-us...@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Chilean mailing list
We've just create a mailing list for discussing about Pharo/Smalltalk in Chile. pharo-ch...@googlegroups.com http://groups.google.com/group/pharo-chile Does it make sense ? I ask because maybe with clubSmalltalk (in Spanish) is enough. Yes it makes sense because most of the members list are from the University of Chile. This means that people know each other. The effect will be different with ClubSmalltalk. Moreover, during my lectures and presentations I talk much more about Pharo than Smalltalk. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Introducing smallUML: a little project to help us document :)
Carla F. Griggio wrote: Let me know what are your projects about and how you would use this :O I've been working on a mind-mapping-like app and some visual browsing tools (e.g. an implementorsOF browser that draws a graph of possible execution paths), and have been implementing connectors-like functionality from scratch, but I'd be happy to give the from scratch part up ;-) Sean -- View this message in context: http://forum.world.st/Introducing-smallUML-a-little-project-to-help-us-document-tp2331341p2945841.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image
On Fri, 1 Oct 2010, Mariano Martinez Peck wrote: On Fri, Oct 1, 2010 at 8:26 AM, Igor Stasenko siguc...@gmail.com wrote: On 1 October 2010 08:48, Mariano Martinez Peck marianop...@gmail.com wrote: On Thu, Sep 30, 2010 at 11:07 PM, Johan Fabry jfa...@dcc.uchile.cl wrote: Hi all, I am planning to put online a minimal image that contains AspectMaps, with some models pre-loaded. Two questions: - Is there an easy way to strip this image of dev tools et cetera? Not really. The easiest way is to have a Configuration of Metacello that takes care of loading all your code with all your dependencies. Then, take a PharoCore and load your code there. In addition, you may want to evaluate ScriptLoader cleanUpForProduction at the end. Check the method to see what it does. - How can I make it so that I can distribute it without the changes file? (Right now the image complains of a missing changes file if it is not there ...) I am aware of Smalltalk abandonSources to avoid using .sources. You won't see things like the temp names, and stuff will be decompiled instead. With a little effort, you can embed source code into method trailers. Then you won't need .sources nor .chanes to see the real source instead of decompiling it. But you will loose method stamps. I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, if I will improve performance since I don't need to fetch a .sources file. what would be awesome is if we can have both, this is: for the dev image, I would like to have the sources in the image, but not for PharoCore. Or maybe also in PharoCore but to be sure to be able to remove them, and use .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction or similar. thoughts? You'd also lose versioning, since a trailer can only hold one version of the source code. Btw, do you really have a performance issue reading the sources? With Cog and Squeak 4.2, I get: methods := CompiledMethod allInstances shuffle. [ methods do: #getSource ] timeToRun === 1162 So it takes ~25 microseconds to fetch the source of a method on average. That's more than 39000 methods per second. It should be enough IMHO. Levente For the .changes you can start the image without them, there will raise a popup at the beginning. The problem is if you then do sometthing that should be written there. Not sure here... yeah. cheers Mariano Thanks in advance! -- Johan Fabry jfa...@dcc.uchile.cl - http://dcc.uchile.cl/~jfabryhttp://dcc.uchile.cl/%7Ejfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile ___ Pharo-users mailing list pharo-us...@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users ___ Pharo-users mailing list pharo-us...@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users -- Best regards, Igor Stasenko AKA sig. ___ Pharo-users mailing list pharo-us...@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [ANN] Pharo-1.1.1-dev10.09.1
Excellent work, thanks Mariano! 2010/10/1 Mariano Martinez Peck marianop...@gmail.com: Hi folks. We are releasing Pharo 1.1.1. This image is exactly same as Pharo 1.1 but based on PharoCore 1.1.1. The versions of the external packages is the same as in Pharo 1.1. The difference is that PharoCore1.1.1 has integrated some fixes and the support for CogVM. This means that Pharo-1.1.1-dev10.09.1 can be run with both, normal PharoVM and CogVM. For CogVM we recommend to use the last binaries that can be found in http://www.mirandabanda.org/files/Cog/VM/. Right now the last one is http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ This CogVM version fixes the problem with Objects as methods, and thus, all the #run:with:with are working. This means that tools like TestCoverage and AutoTest are working correctly with CogVM. The link to the image is: https://gforge.inria.fr/frs/download.php/27543/Pharo-1.1.1-dev10.09.1.zip Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] A Mentoring Course on Smalltalk Code License
I am not sure the code in the book needs a license. After all, eventually you will get the distribution for the source code in question and then you will (should) have an MIT license... does that make sense? On 9/30/10 19:23 , Sean P. DeNigris wrote: 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? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Source in image [WAS] Re: [Pharo-users] Distributing 'minimal' image
I WOULD LOVE that. I mean, I don't care if the dev image is 10 mb bigger, if I will improve performance since I don't need to fetch a .sources file. what would be awesome is if we can have both, this is: for the dev image, I would like to have the sources in the image, but not for PharoCore. Or maybe also in PharoCore but to be sure to be able to remove them, and use .sources/decompiler as it is now. Maybe put that in #cleanUpForProduction or similar. thoughts? You'd also lose versioning, since a trailer can only hold one version of the source code. Btw, do you really have a performance issue reading the sources? With Cog and Squeak 4.2, I get: methods := CompiledMethod allInstances shuffle. [ methods do: #getSource ] timeToRun === 1162 So it takes ~25 microseconds to fetch the source of a method on average. That's more than 39000 methods per second. It should be enough IMHO. Well, you can always change the trailer(s) to hold additional info. As i told before, we need a source management layer, which allows multiple different implementations, then its not quite important how/where we persisting sources, since we could switch between them, or use different source manager on a per-method basis. Levente -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
