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

Re: [Pharo-project] Speeding up Finder string search

by Stefan Marr

Hi: On 16 Jan 2012, at 14:50, Stefan Marr wrote: > Hi: > > On 16 Jan 2012, at 14:31, Camillo Bruni wrote: > >> I guess having the sources completely in the image is the straight-forward solution to this :/ > > Well, we could also cache just the resulting source string. > Not sure what that means in terms of memory, but going to the file every time a method is asked for its code seems to be very naive. I put a cache (IdentityDictionary) methodSource into Class. That requires recompiling all classes which takes a while, and I do not know, whether it should not be in ClassDescription. And guess what: The bad news: the image size doubles from 22.2MB to 39.5MB. The good news: "before using cache" #(43239 23490 22084) #(20581 20238 20207) The 43239 created all dictionaries. "warming up and using cache" #(20177 1428 1393) #(1389 1374 1400) That is a pretty nice speedup, grep is still a faster, but now finder becomes usable! I use the cache like this: CompiledMethod>>getSourceFromFile "Read the source code from file, determining source file index and file position from the last 3 bytes of this method." | position classSrc | classSrc := self methodClass getSourceFor: self selector. classSrc ifNotNil: [ ^ classSrc]. (position := self filePosition) = 0 ifTrue: [^ nil]. classSrc := (RemoteString newFileNumber: self fileIndex position: position) string. self methodClass setSourceFor: self selector to: classSrc. ^ classSrc To me that feels all pretty straight forward and naive, so feel free to have better ideas. Perhaps the cache should get evicted when not used, etc... Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 16, 2012

[Pharo-project] loading subclasses of non existing superclasses with Monticello

by Mariano Martinez Peck

Hi guys. I noticed that when loading a package with classes whose superclasses are not present in the image, and the Monticello popup appears, then those subclasses are not loaded at all. I think I remember they were loaded anyway as a subclass from an obsolete class. But I have just checked in pharo 1.2, 1.3 and 1.4 and the subclasses are not loaded at all :( So...I am just crazy or it used to be that way and then it changed? thanks -- Mariano http://marianopeck.wordpress.com

Jan. 16, 2012

Re: [Pharo-project] Squeaksource down again

by Fabrizio Perin

No problem, I'm sorry i cannot do anything until tomorrow. Cheers, Fabrizio 2012/1/16 Frank Shearar <frank.shearar(a)gmail.com> > Thanks, Fabrizio. It did indeed look more serious than SS being > difficult: I was getting No Route to Host errors, so looked more > network related than SS. > > frank > > On 16 January 2012 16:54, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote: > > Well, all our servers are down. Try tommorow. > > > > > > > > 2012/1/16 Frank Shearar <frank.shearar(a)gmail.com> > >> > >> http://www.downforeveryoneorjustme.com/www.squeaksource.com > >> > >> Hooray for ss3.gemstone.com! > >> > >> frank > >> > > > >

Jan. 16, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Sean P. DeNigris

After pounding at the system and countless books/articles/keynotes, I get that Smalltalk is a vision, not a syntax. Fortunately, I was hooked from the beginning by Alan Kay's TED Talk, so I enthusiastically pushed through the pain of adapting to the image, losing my vi bindings, etc. If it was only about syntax, without the live, open, dynamic, turtles-all-the-way-down system, I would probably use Ruby, which has more of the libraries I need and want (although I would definitely miss passing blocks as any argument, and keywords are nice). *However*, like any "blue plane" idea, there are people that don't get it (and actually /can't/ get it) and want to relate to Smalltalk as "a language with cool syntax", giving up the productivity of a live environment. This is the nature of paradigm shift. Now, while I feel bad that those people are totally missing out on the magic, if they are willing to join our community and contribute to the libraries, fix bugs, user test, etc., let's welcome them with crappy (i.e. standard) tools and reap the benefits of more pairs of hands and eyes. I'm sure it won't be long before they are pair programming with or watching someone at ESUG/Smalltalks/STIC who "gets it". When they start zipping through senders and implementors, inspecting live objects, and opening debuggers, I'm sure many will start to understand. Not all popcorn kernels pop at the same time. Hopefully, one of the converts will finally implement vi bindings in the image development tools before I get around to doing the work ;-) Sean -- View this message in context: http://forum.world.st/Misc-newbie-questions-tp4268310p4301259.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 16, 2012

Re: [Pharo-project] [COTDC] 105 - ZipConstants

by Sean P. DeNigris

Thanks, Ben! -- View this message in context: http://forum.world.st/COTDC-105-ZipConstants-tp4297275p4301205.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 16, 2012

Re: [Pharo-project] Squeaksource mirror

by Max Leske

THANK YOU CHILE! You just saved my night :) Max On Mon, Jan 16, 2012 at 6:36 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > Hmm, What do you think about having this loaded in the core image, and a > setting for it? :D > > I can't remember all the time how to download it :( > > ---------- Forwarded message ---------- > From: Francois Stephany <tulipe.moutarde(a)gmail.com> > Date: Tue, Jan 10, 2012 at 9:27 PM > Subject: Re: [Pharo-project] Squeaksource is... up, but just barely > To: pharo-project(a)lists.gforge.inria.fr > > > Same here. Timeouts when loading stuff :/ > > In the mean time I use the Chilean mirror. Pretty simple: > > Gofer new > url: 'http://dsal.cl/squeaksource/**MonticelloRedirect<http://dsal.cl/squeaksource/MonticelloRedirect> > '; > package: 'MontiRedirect'; > load. > > MRManager redirectFrom: 'http://www.squeaksource.com/' to: ' > http://dsal.cl/squeaksource/'**. > > > > > On 10/01/12 15:54, Sean P. DeNigris wrote: > >> It's very... very... slow... (enough that Metacello loads are timing out) >> >> -- >> View this message in context: http://forum.world.st/** >> Squeaksource-is-up-but-just-**barely-tp4283895p4283895.html<http://forum.world.st/Squeaksource-is-up-but-just-barely-tp4283895p4283895.…> >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > -- > http://tulipemoutarde.be > BE: +32 (0)65 709 131 > CA: +1 778 558 3225 > > >

Jan. 16, 2012

[Pharo-project] Monticello mirror not installing in Pharo 1.4

by Guillermo Polito

First, it needs ObjectAsMethodWrapper, which is not any more in the 1.4 image :) Second, ObjectAsMethodWrapper uses MethodReference, causing an infinite recursion when installing the mirror. I fixed this changing the method *#on:selector: *by on: aClass selector: aSelector ^self on: (RGMethodDefinition class: aClass selector: aSelector) Guille

Jan. 16, 2012

[Pharo-project] in the quest of HazelNut: the crazy on:do: influence :)

by StÃ©phane Ducasse

hi guys I'm playing with Hazeltracer and I generate 3.4 mb image with Opal. Now I have one single process that one :) and I do not understand because the following code work: I get 33 in the file. No stack dump. freshProcessWorkingWithOpalLoaded ^ [ |file| [ file := StandardFileStream fileNamed: 'loglog.txt'. file nextPutAll: 'Start'. [ file nextPutAll: ((OCClosureCompiler new compile: 'foo ^ 33.' in: Object classified: nil notifying: nil ifFail: []) generate valueWithReceiver: Object new arguments: #()) asString] on: Error do: [:ex | ex outer errorReportOn: file]. ] ensure: [file close]. [true] whileTrue: [Beeper primitiveBeep. ]] newProcess while this one does not :). I do not get the influence of the on:do: freshProcessWorkingWithOpalLoaded ^ [ |file| [ file := StandardFileStream fileNamed: 'loglog.txt'. file nextPutAll: 'Start'. file nextPutAll: ((OCClosureCompiler new compile: 'foo ^ 33.' in: Object classified: nil notifying: nil ifFail: []) generate valueWithReceiver: Object new arguments: #()) asString ] ensure: [file close]. [true] whileTrue: [Beeper primitiveBeep. ]] newProcess any idea? Stef

Jan. 16, 2012

Re: [Pharo-project] [COTDC] 105 - ZipConstants

by StÃ©phane Ducasse

excellent! On Jan 16, 2012, at 4:50 PM, Ben Coman wrote: > sean(a)clipperadams.com wrote: >> 104 classes done >> 793 classes remaining >> Continuing in Compression... >> >> Today: ZipConstants >> >> Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >> >> p.s. this message was sent from a pharo image. Did you know you could easily do that?! >> >> >> > > This class defines magic numbers taken from RFC1951 [1b], and also possibly RFC1950 [1a] & RFC1952 [1c]. > It presets some dictionary structures as described at [1a] 8.1. > > A class can import these bindings as 'class variables' by including the following in its class definition: > poolDictionaries: 'ZipFileConstants' > > Following are source references to these constants contained within several class side initialization methods. (These might be better spread through out those methods as time permits) > > initializeDeflateConstants > WindowSize [2e]"w_size", [2a]"windowBits is the base two logarithm of windowSize where default windowBits=15" > WindowMask [2e]"w_mask" > MaxDistance [2e]"MAX_DIST" > MinMatch [2c] > MaxMatch [2c] > HashBits [2e]"hash_bits" > HashMask [2e]"hash_mask" > HashShift [2e]"hash_shift" > > initializeDistanceCodes > BaseDistance [2f] > DistanceCodes [2f] > > initializeExtraBits > ExtraLengthBits [1]3.2.5, [2b] > ExtraDistanceBits [1]3.2.5, [2b] > ExtraBitLengthBits [2b] > BitLengthOrder [1]3.2.7, [2b] > > initializeFixedTrees > [1]3.2.6 > > initializeWriteStreamConstants > MaxBits [2d] > MaxBitLengthBits [2b] > EndBlock [2b] > StoredBlock [2c] > FixedBlock [2c] > DynamicBlock [2c] [1]3.2.3"BTYPE" > NumLiterals > MaxLengthCodes [2e] > MaxDistCodes [2e] > MaxBitLengthCodes [2e] > MaxLiteralCodes > Repeat3To6 [2b] > Repeat3To10 [2b] > Repeat11To138 [2b] > > [1a] "ZLIB Compressed Data Format Specification version 3.3" http://www.ietf.org/rfc/rfc1950.txt > [1b] "DEFLATE Compressed Data Format Specification version 1.3" http://www.ietf.org/rfc/rfc1951.txt > [1c] "GZIP file format specification version 4.3" http://www.ietf.org/rfc/rfc1952.txt > [2] ZLIB Source Code http://zlib.net/zlib-1.2.5.tar.gz > [2a] zlib.h > [2b] trees.c > [2c] zutil.h > [2d] inftrees.c > [2e] deflate.h > [2f] trees.h > >

Jan. 16, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by StÃ©phane Ducasse

Thanks jimmie :) You summarize well some of my thoughts. Stef going back to talk to an image with one process and no ui and trying to get a repl so that I can debug our 3.2 mb image :). Yes the way to bootstrapping is slow :) > On 1/15/2012 6:55 AM, Gerry Weaver wrote: >> Hi Andreas, >> >>> I am not comfortable with the idea to write parts of an application in >>> different languages. >>> Typically the disadvantages overweigh the advantages to do so as you >>> would have different languages and systems to master and update. >>> Interoperability with other systems and languages should be easy and >>> Squeak/Pharo are still lacking in this area. This is well known and >>> hopefully there will be some improvements in the future. >> >> I guess I would have to disagree with you here. Most of the editors and >> IDEs of other languages are not maintained by the language proper. There >> are many editors and IDEs that support many languages in addition to the >> one they are written in. I think the benefits of using a full featured >> GUI toolkit to create an IDE would be significant. > > And I have to disagree with you here. You lack the imagination and knowledge to understand the significant advantage of having a single language, environment and toolset that Smalltalk provides. > >>> Planning to give up on parts like GUI is a bad idea in my opinion. >>> Smalltalk would be even more niche than it is now. I want to be able to >>> build complete applications without the need to build parts in another >>> language. >> >> In theory I would agree with you. However, I wasn't able to come up with >> an application scenario where the Pharo GUI would work. Either the >> widget set and OS integration are too limited or performance is a >> problem. For example, the last several applications I have done needed >> to display PDF files. I have done a little testing with Pharo and I'm >> sorry to say the results were not very encouraging. The problem I think >> is one of limited resources. I think that maybe trimming some things >> would render more progress on the core. Perhaps a good and complete >> binding to one of the current GUI toolkits would be easier to maintain. >> You would also get the instant advantage of everything the toolkit had >> to offer (including performance). A more robust FFI would inevitably be >> realized as a result. > > Again, I think you lack imagination. You are stuck in box built by all your previous tools and experience. And from your box you are trying to look at Smalltalk and trying to shape it to your experience and thusly declaring its deficiencies. This does not make Smalltalk wrong. > > Most of us here like the Smalltalk experience. We like the language. We like the image. Are there issues that we would like to overcome? Of course. Outside of interfacing with the outside world being made easier, I don't think you are really addressing those issues. Instead, your are creating issues we don't have. And many of us find many things we can do living in our world and slowly working on what our world can access. > > If you want to mold Pharo into the image that you think it should be. Please feel free to do so. It is open source. Fork it and make it so. We would even help where we are able. But you are going outside of the vision and worldview of this community and most any Smalltalk community. > > Cincom, Gemstone, or any of the other commercial Smalltalks have reasonable success despite all the deficiencies you have discovered. > > And if you decide that Smalltalk doesn't fit your worldview. That is ok. Find the tool that fits you. Be productive with it. And if you want to create what you think is a better way with what you learn from Smalltalk. Go for it. > > As far as GUI. I like ours. I think it can be improved greatly. But I like access to it as part of my environment. > > What is a standard UI? Who set this standard? Why is QT standard? or WxWidgets or ...? Look at the most used apps out there. Are they using native standard UI? I don't think so. iTunes is a hugely used app. Is it standard UI? No. Apple Mail? Safari? Windows Media player? No these things are used by most of the computing world and they don't even use the normal standard native UI of their platform. And they are all ugly. > > Is Facebook standard? Web apps are used all the time. > > Who says what is standard. And is what is standard today, what we should strive for? Or can we work towards a better future. > > I use all kinds of applications which do not meet your standard of being a native standard UI. But I use them. Why? Because they provide the abilities to do what I want or need. Not because they meet any particular standards as defined by nameless potentially clueless people. > > So more than meeting any particularly defined standard of UI, what is required is than an application be compelling. If it is not, then no matter how standards compliant it will meet with little receptiveness. > > Is Eclipse, Netbeans, Vi, Emacs standard. Windows or Mac? If Windows, XP, Vista, 7, 8? What is standard on Linux? KDE, Gnome, Unity, pick your favorite WM. So why is it your developers get to use non-standard tools, (Emacs, Vi), or define then standard as being what they use? > > There are lots of applications where the UI is almost never standard by anyone's definition. In my world financial investment apps. Education apps, games, ... > > This argument passes no reasonable standard. > >>> Especially having the IDE in Smalltalk itself and thus being able to >>> inspect and debug and modify everything is a big advantage over any IDE >>> in a different language. >> >>> I don't understand why the IDE needs to be in the image/language to do that. >>> All Smalltalk implementations have shortcomings in some areas. There >>> are a multitude of reasons for it, be it commercially >>> (greater estimated expenses than earnings from it) or just lack of >>> capacity. Smalltalk users are rare these days and the community is >>> split because of different implementations and interests. For me, Pharo >>> is on a good way to take the Smalltalk language into a better >>> ecosystem. But for the moment Dolphin Smalltalk is my preferred system >>> because it's relatively cheap and has only few known bugs. In my eyes >>> it deserves a bigger community and better commercial success. But I >>> guess that's what every Smalltalker thinks about his preferred >>> Smalltalk system... >> >> Dolphin seems to be one of the better implementations, but the problem >> with Dolphin is Windows. All of the projects on my radar right now are >> moving applications away from Windows to Mac/Linux (mostly Mac). > > So, in this statement, by definition you are moving from the most standard defined UI to lesser standard UIs. Linux is all over the map. > > The above are simply my opinions and I make no express statements that anyone else in the Pharo community agrees with them. > > Personally I am all for improving the Pharo worlds and making more things accessible within that world. Not necessarily becoming like the world outside of Pharo/Smalltalk. If I want that world, it is already there. > > I would also presume that by your exploration of our little world, which by the way is 30+ years old, that you have sufficient deficiencies in the world you come from to explore what else is available. > > Jimmie > >

Jan. 16, 2012