August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] latest filesystem is unloadable

by Camillo Bruni

The issue is the Version FS-Disk-cwp.2 which introduces most probably a rename and pushed down the Primitive var. Seems like whoever (cwp? I'd appreciate long namesâ¦) committed it forgot a piece ;) cami On 2011-08-15, at 23:31, Tudor Girba wrote: > Hi, > > The bleeding edge version of Filesystem is unloadable in Pharo 1.3 (see the attached debug log). > > To test it, try: > > Gofer new > squeaksource: 'fs'; > package: 'ConfigurationOfFilesystem'; > load. > (Smalltalk at: #ConfigurationOfFilesystem) loadBleedingEdge > > Cheers, > Doru

Aug. 15, 2011

Re: [Pharo-project] latest filesystem is unloadable

by Tudor Girba

Hi, Continuous integration is there to test continuously. I was not complaining :). I just reported this issue, especially given that it is a critical one (not being able to load the code). The problem appeared today, because yesterday it worked fine. But, where is 2.2.1? I load the code from the Configuration from the official www.squeaksource.com/fs.html repository, and there the latest version is 2.0.2. Cheers, Doru On 15 Aug 2011, at 23:52, StÃ©phane Ducasse wrote: > Why do you want to load the bleeding edge since 2.2.1 is fully tagged for reproduceability. I never used loadBleedingEdge and I did not garantee that it would work. > > Stef > > > On Aug 15, 2011, at 11:31 PM, Tudor Girba wrote: > >> Hi, >> >> The bleeding edge version of Filesystem is unloadable in Pharo 1.3 (see the attached debug log). >> >> To test it, try: >> >> Gofer new >> squeaksource: 'fs'; >> package: 'ConfigurationOfFilesystem'; >> load. >> (Smalltalk at: #ConfigurationOfFilesystem) loadBleedingEdge >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "From an abstract enough point of view, any two things are similar." >> >> >> <PharoDebug.log.zip> > > -- www.tudorgirba.com "Live like you mean it."

Aug. 15, 2011

Re: [Pharo-project] latest filesystem is unloadable

by StÃ©phane Ducasse

Why do you want to load the bleeding edge since 2.2.1 is fully tagged for reproduceability. I never used loadBleedingEdge and I did not garantee that it would work. Stef On Aug 15, 2011, at 11:31 PM, Tudor Girba wrote: > Hi, > > The bleeding edge version of Filesystem is unloadable in Pharo 1.3 (see the attached debug log). > > To test it, try: > > Gofer new > squeaksource: 'fs'; > package: 'ConfigurationOfFilesystem'; > load. > (Smalltalk at: #ConfigurationOfFilesystem) loadBleedingEdge > > Cheers, > Doru > > -- > www.tudorgirba.com > > "From an abstract enough point of view, any two things are similar." > > > <PharoDebug.log.zip>

Aug. 15, 2011

Re: [Pharo-project] If someone wants to know something about Fuel...

by Javier PimÃ¡s

I do! On Mon, Aug 15, 2011 at 3:56 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > I'll be giving a talk in ESUG and presenting such project in the awards. > So...I will be the whole week there. If someone wants to ask something or > hack together with Fuel, please let me know. > > Cheers > > -- > Mariano > http://marianopeck.wordpress.com > > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Aug. 15, 2011

Re: [Pharo-project] optimizing primitiveFindFirstInString

by Levente Uzonyi

On Mon, 15 Aug 2011, Philippe Marschall wrote: > On 15.08.2011 18:07, Levente Uzonyi wrote: >> On Mon, 15 Aug 2011, Philippe Marschall wrote: >> >>> On 15.08.2011 00:21, Levente Uzonyi wrote: >>>> On Sun, 14 Aug 2011, Philippe Marschall wrote: >>>> >>>>> On 14.08.2011 22:00, Levente Uzonyi wrote: >>>>>> On Sun, 14 Aug 2011, Philippe Marschall wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> In Seaside we get a lot of performance gains out of >>>>>>> primitiveFindFirstInString. One thing that always annoyed me a bit is >>>>>>> that it's not as optimized as it could be. >>>>>>> >>>>>>> The inclusionMap you give it are 256 consecutive boolean values (0 or >>>>>>> 1). There is no need for this to be a 256 element ByteArray when each >>>>>>> element can only be 0 or 1. We could as well make it a 32 element >>>>>>> ByteArray and each byte holding eight bit values. Instead of using >>>>>>> the >>>>>>> asciiValue to directly index into the inclusionMap we would use >>>>>>> the top >>>>>>> five bits to index into the inclusionMap and the bottom 3 bits to >>>>>>> "index >>>>>>> into the byte". >>>>>>> >>>>>>> Did that make any sense? >>>>>> >>>>>> Do you want to save space? >>>>> >>>>> I'm trying to trade memory access (which is slow) for a bit shift and >>>>> two bit ands (which is fast). >>>> >>>> 256 bytes + object header easily fit into the L1 cache of any recent x86 >>>> CPU, even the old P4's had 8kB of it. >>> >>> Sure once it's in the cache then it's in the cache. But a cache line is >>> only 64 bytes. So a 32 element array should fit and a 256 element >>> doesn't. So a 32 element array should be there in one memory access >>> while a 256 element array probably takes five. >> >> A 32 element array needs 1-2 cache lines, while the 256 element array >> needs 4-5. It's not that big difference IMHO. (Especially if you want to >> pass a ByteArray and convert it ot a 32 byte array in C.) >> >>> >>>> Moving less bytes around may make >>>> some difference though, but if you create your ByteArrays right before >>>> you use them, then it's pretty likely that your object is already in the >>>> cache. >>> >>> I don't of course. >>> >>>>> >>>>>> Are you storing lots of inclusion maps (maybe >>>>>> CharacterSets)? If not, then IMHO it's not worth to adding this >>>>>> feature >>>>>> to this primitive, because runtime performance will be worse on >>>>>> both the >>>>>> image side and the VM side. >>>>> >>>>> Why? >>>> >>>> Filling the contents of a compact 32 sized ByteArray in the image takes >>>> more time than a 256 byte ByteArray. On the VM side memory access + >>>> shifts + bitands cost more than just memory access. >>> >>> Uhm, it's a primitive. My understanding is this would result in "C >>> shifts + bitands". >> >> Hm. Are you about to change the primitive to create an array of 32 bytes >> from the ByteArray argument and use that during the search? > > Of course not. I'm going to create a new primitive that takes a 32 > element byte array. Anything else is pointless. Okay, so you will create the 32 sized ByteArrays in the image as I first thought. This means that the initialization of the ByteArrays will take more time. Btw I wouldn't create a new primitive. The current primitive only accepts 256 sized ByteArrays, so adding support for 32 byte ByteArrays won't cause any trouble and you can reuse all existing image side code. > >>> >>>> But (as usual) a >>>> benchmark can tell if it's really worth to do it or not. >>> >>> This there somewhere some documentation how one adds a primitive and >>> compiles a VM (Cog ideally)? >> >> This primitive is in the image, search for the method with the string >> 'primitiveFindFirstInString'. The same way you can add others methods to >> MiscPrimitivePlugin. IIRC there's a registry (an array in a method on >> the plugin's class' side) for these methods where you should add the new >> method, look for the method name (as string/symbol) to find it. > > That part is clear to me. > >> There are multiple ways to build VMs, but I guess you want to follow the >> way developed by Igor. > > That part is not at all clear to me. Where can I find documentation > about this. I guess this is what you are looking for: http://marianopeck.wordpress.com/2011/04/10/building-the-vm-from-scratch-us… Levente > > Cheers > Philippe > > >

Aug. 15, 2011

[Pharo-project] latest filesystem is unloadable

by Tudor Girba

Hi, The bleeding edge version of Filesystem is unloadable in Pharo 1.3 (see the attached debug log). To test it, try: Gofer new squeaksource: 'fs'; package: 'ConfigurationOfFilesystem'; load. (Smalltalk at: #ConfigurationOfFilesystem) loadBleedingEdge Cheers, Doru -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

Aug. 15, 2011

Re: [Pharo-project] optimizing primitiveFindFirstInString

by Mariano Martinez Peck

> > > There are multiple ways to build VMs, but I guess you want to follow the > > way developed by Igor. > > That part is not at all clear to me. Where can I find documentation > about this. > > Well, I tried to document as much as possible: http://code.google.com/p/cog/wiki/Guide -- Mariano http://marianopeck.wordpress.com

Aug. 15, 2011

[Pharo-project] If someone wants to know something about Fuel...

by Mariano Martinez Peck

I'll be giving a talk in ESUG and presenting such project in the awards. So...I will be the whole week there. If someone wants to ask something or hack together with Fuel, please let me know. Cheers -- Mariano http://marianopeck.wordpress.com

Aug. 15, 2011

Re: [Pharo-project] optimizing primitiveFindFirstInString

by Philippe Marschall

On 15.08.2011 18:07, Levente Uzonyi wrote: > On Mon, 15 Aug 2011, Philippe Marschall wrote: > >> On 15.08.2011 00:21, Levente Uzonyi wrote: >>> On Sun, 14 Aug 2011, Philippe Marschall wrote: >>> >>>> On 14.08.2011 22:00, Levente Uzonyi wrote: >>>>> On Sun, 14 Aug 2011, Philippe Marschall wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> In Seaside we get a lot of performance gains out of >>>>>> primitiveFindFirstInString. One thing that always annoyed me a bit is >>>>>> that it's not as optimized as it could be. >>>>>> >>>>>> The inclusionMap you give it are 256 consecutive boolean values (0 or >>>>>> 1). There is no need for this to be a 256 element ByteArray when each >>>>>> element can only be 0 or 1. We could as well make it a 32 element >>>>>> ByteArray and each byte holding eight bit values. Instead of using >>>>>> the >>>>>> asciiValue to directly index into the inclusionMap we would use >>>>>> the top >>>>>> five bits to index into the inclusionMap and the bottom 3 bits to >>>>>> "index >>>>>> into the byte". >>>>>> >>>>>> Did that make any sense? >>>>> >>>>> Do you want to save space? >>>> >>>> I'm trying to trade memory access (which is slow) for a bit shift and >>>> two bit ands (which is fast). >>> >>> 256 bytes + object header easily fit into the L1 cache of any recent x86 >>> CPU, even the old P4's had 8kB of it. >> >> Sure once it's in the cache then it's in the cache. But a cache line is >> only 64 bytes. So a 32 element array should fit and a 256 element >> doesn't. So a 32 element array should be there in one memory access >> while a 256 element array probably takes five. > > A 32 element array needs 1-2 cache lines, while the 256 element array > needs 4-5. It's not that big difference IMHO. (Especially if you want to > pass a ByteArray and convert it ot a 32 byte array in C.) > >> >>> Moving less bytes around may make >>> some difference though, but if you create your ByteArrays right before >>> you use them, then it's pretty likely that your object is already in the >>> cache. >> >> I don't of course. >> >>>> >>>>> Are you storing lots of inclusion maps (maybe >>>>> CharacterSets)? If not, then IMHO it's not worth to adding this >>>>> feature >>>>> to this primitive, because runtime performance will be worse on >>>>> both the >>>>> image side and the VM side. >>>> >>>> Why? >>> >>> Filling the contents of a compact 32 sized ByteArray in the image takes >>> more time than a 256 byte ByteArray. On the VM side memory access + >>> shifts + bitands cost more than just memory access. >> >> Uhm, it's a primitive. My understanding is this would result in "C >> shifts + bitands". > > Hm. Are you about to change the primitive to create an array of 32 bytes > from the ByteArray argument and use that during the search? Of course not. I'm going to create a new primitive that takes a 32 element byte array. Anything else is pointless. >> >>> But (as usual) a >>> benchmark can tell if it's really worth to do it or not. >> >> This there somewhere some documentation how one adds a primitive and >> compiles a VM (Cog ideally)? > > This primitive is in the image, search for the method with the string > 'primitiveFindFirstInString'. The same way you can add others methods to > MiscPrimitivePlugin. IIRC there's a registry (an array in a method on > the plugin's class' side) for these methods where you should add the new > method, look for the method name (as string/symbol) to find it. That part is clear to me. > There are multiple ways to build VMs, but I guess you want to follow the > way developed by Igor. That part is not at all clear to me. Where can I find documentation about this. Cheers Philippe

Aug. 15, 2011

Re: [Pharo-project] [Esug-list] Smalltalk lecture Saturday 20th of August at ESUG

by StÃ©phane Ducasse

I do not think so. Nothing was prepared for that, now you can get the slides (some version on my lecture web pages). Stef On Aug 15, 2011, at 4:49 PM, HwaJongOh wrote: > can i watch this via internet? > > Best Regards > HwaJogn Oh > > 2011. 8. 14., ì ë 5:13, StÃ©phane Ducasse ìì±: > >> Hi Friends please distribute that widely >> >> >> I will give a free lecture >> >> >> Discovering Smalltalk >> >> Smalltalk is a pure and elegant object language. This lectures will cover the fundamental aspects of Smalltalk: >> syntax, semantics, and key aspects of the system. Doing so we will also revise the real semantics of self/super. >> We will show the power of polymorphism in action by simply learning from the system. Finally we will go into >> more design aspect again based on the systems. As a bonus we will start the lecture with a 15 min presentation >> of Seaside a powerful web framework for dynamic web application. >> >> This lecture may be followed by a lecture on more advanced object-oriented design: >> law of demeter, encapsulation, multiple interface of classes, composition vs. inheritance >> >> Starting time: 9h30 >> Closing: 16h00 >> >> Location: http://www.esug.org/wiki/pier/Conferences/2011/The-Venue-in-Edinburgh >> >> >> >> Bio: He is expert in object-oriented language design, dynamic languages, reflective programming, language semantics as well as reengineering, program analysis, >> visualizations, software metrics. Recently he worked on traits, composable method groups, and this work got some impact. Traits have been introduced AmbiantTalk, >> Pharo, Perl-6, PHP 5.4 and Squeak. They influenced Scala and Fortress SUN Microsystems. Stephane is one of the developer of Pharo (http://www.pharo.project.org/) >> an open-source language inspired by Smalltalk. He is one of the core developer of Moose, an open-source reengineering environment (http://moose.unibe.ch/) >> He is the president of the European Smalltalk User Group and organize a yearly international conference on Smalltalk. He wrote a couple of fun books to teach >> programming and other serious topics such as dynamic web development (http://book.seaside.st) >> >> Stef >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Aug. 15, 2011