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

[Pharo-project] Squeaksource down again

by Frank Shearar

http://www.downforeveryoneorjustme.com/www.squeaksource.com Hooray for ss3.gemstone.com! frank

Jan. 16, 2012

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

by Ben Coman

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] Speeding up Finder string search

by Stefan Marr

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. How does Ring do it? > or using a native tool to grep the source files and then use the results to map back to the methods Ehm, that sounds very brittle, except if you got a nice file representation of your code of course ;) Levente pointed out to me that he introduced a smarter approach to caching in Squeak, with similar performance improvements, and he was thinking about improving that to a process-local variable. Perhaps also an option. 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

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

by Camillo Bruni

I guess having the sources completely in the image is the straight-forward solution to this :/ or using a native tool to grep the source files and then use the results to map back to the methods cami On 2012-01-15, at 18:54, Benjamin wrote: > Thanks for having a look at this problem. > > With Camillo, we though about using parallel processes but never go further than an idea :) > > > Ben > > On Jan 15, 2012, at 6:11 PM, Stefan Marr wrote: > >> Hi: >> >> The finder is annoyingly slow when doing string searches. >> Compared to a 'grep' its multiple magnitudes slower, at least from my perception :( >> >> Profiling pointed my at RemoteString>>string and its use of readOnlyCopy on the SourceFiles. >> >> I put a cache of these read only files into ExpandedSourceFileArray and get a nice speedup. >> >> { [ Finder new constructSourceDictionary ] timeToRun. >> [ Finder new constructSourceDictionary ] timeToRun. >> [ Finder new constructSourceDictionary ] timeToRun . } >> >> Without Cache: #(32079 29034 32274) >> With Cache: #(10757 10718 11050) >> >> >> While that works for the searching, it does fall apart for other uses of RemoteString>>string. (For instance, filing out the changes...) >> >> >> If anyone has an idea how to avoid the overhead of copying, I would be all ears. >> >> >> Thanks >> 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

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

by Frank Shearar

On 16 January 2012 09:59, Lawson English <lenglish5(a)cox.net> wrote: > On 1/15/12 6:44 PM, Jimmie Houchin wrote: >> >> 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. > > > I agree that there is an advantage to having a unified IDE/environment/etc, > but Smalltalk IS stuck in the past in that it doesn't take advantage of > multiple cores. I'm not talking about multi-threading in the usual sense, > but things like the ability to debug one image from another so that the > errors that pop up in the application under development don't affect the > environment being used TO development that application. This issue pops up > most obviously when trying to debug Cobalt/Croquet in a multi-user > configuration, but arises all the time, especially when external libraries > (e.g. OpenGL) are being used and errors occur that the current toolset isn't > designed to accommodate. > > We need to develop better ways of doing things, both for individual and > collaborative environments. IOW, we need spoon and teatime and various other > solutions to mature and work together. If only we knew some folks working on the problem... http://marcusdenker.de/publications/Casa09aObjectSpaces.pdf :) Of course, there's a bit of elbow grease required to turn a research topic into a production-ready system. frank

Jan. 16, 2012

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

by Lawson English

On 1/15/12 6:44 PM, Jimmie Houchin wrote: > 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. I agree that there is an advantage to having a unified IDE/environment/etc, but Smalltalk IS stuck in the past in that it doesn't take advantage of multiple cores. I'm not talking about multi-threading in the usual sense, but things like the ability to debug one image from another so that the errors that pop up in the application under development don't affect the environment being used TO development that application. This issue pops up most obviously when trying to debug Cobalt/Croquet in a multi-user configuration, but arises all the time, especially when external libraries (e.g. OpenGL) are being used and errors occur that the current toolset isn't designed to accommodate. We need to develop better ways of doing things, both for individual and collaborative environments. IOW, we need spoon and teatime and various other solutions to mature and work together. L.

Jan. 16, 2012

Re: [Pharo-project] [Pharo-users] OCompletion configuration for 1.4

by Luc Fabresse

yes. Thanks Guillermo! Luc 2012/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Thanks thanks thanks and â¦ thanks > > Stef > On Jan 13, 2012, at 10:53 PM, Mariano Martinez Peck wrote: > > > Thanks Guille. It works perfect. I have just commited a small fix in > Ocompletion-MarianoMartinezPeck.114 ;) > > > > cheers > > > > On Fri, Jan 13, 2012 at 10:34 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > > On 13 January 2012 17:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Thanks a lot!!!! > > > > > yeah, i just checked and it works out of the box. good job! > > > > > Stef > > > > > > On Jan 13, 2012, at 3:53 PM, Guillermo Polito wrote: > > > > > >> I've written a new version of OCompletion for 1.4 with several fixes > and compatibility additions for Pharo 1.4 > > >> > > >> Gofer it > > >> squeaksource: 'MetacelloRepository'; > > >> package: 'ConfigurationOfOCompletion'; > > >> load. > > >> > > >> ConfigurationOfOCompletion loadStable > > >> > > >> If someone wants to try it :). > > >> > > >> Guille > > > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > >

Jan. 16, 2012

Re: [Pharo-project] startup errors

by Andrea BrÂÃ¼hlmann

Hi there, Could anyone please have a look at issue 5045? I am running into big troubles from time to time because of images that cannot be opened anymore because there happens an error somewhere during startup. The discussed option would allow image recovery without hacking the bytecode! Thanks Andrea Andrea BrÂÃ¼hlmann schrieb: > I tested it a bit in a fresh 1.3 image and opened the issue 5045, > maybe we can continue the discussion there. The feature would be great! > > Andrea > > > > Igor Stasenko schrieb: >> On 26 October 2011 11:51, Andrea BrÃ¼hlmann <a.bruehlmann(a)netstyle.ch> >> wrote: >> >>> I tried it with this option now, but it did not solve the problem, >>> because >>> it just saved a new version of the image and quit, but did not open a >>> debugger. Opening the new version does the same as the original. Did >>> I miss >>> something? >>> >>> >> It should open a debugger. if not, then this is a bug :) >> It might be, that if error happens in startup phase, then it is not >> opens a debugger. >> >> >>> I would appreciate a command line option that either opens a >>> debugger or >>> ignores the errors, because like this you usually have a clean image >>> but if >>> you have a problem, you can open the image and do something. >>> >>> Andrea >>> >>> Igor Stasenko schrieb: >>> >>>> On 25 October 2011 23:26, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >>>> wrote: >>>> >>>>> Sig, >>>>> >>>>> All too true, and very pure. But what if I just want to save a >>>>> package, >>>>> or some data, that might be locked away in the image? Code is >>>>> generally >>>>> safe, since one can recover lost changes into a healthy image, but >>>>> there can >>>>> still be other data lurking in an image. >>>>> >>>>> A middle-ground approach would be to have command line option that >>>>> lets >>>>> the image run. One should run w/o it to bring errors to >>>>> attention, but at >>>>> least it would be possible to override and at least have an >>>>> opportunity to >>>>> recover endangered bits. >>>>> >>>>> >>>> look at settings, there's already an option to save a new version of >>>> image before quit. >>>> if you turn this option on, then any unhandled error will open a >>>> debugger if you open an image saved in such state. >>>> >>>> >>>>> Bill >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor >>>>> Stasenko >>>>> [siguctua(a)gmail.com] >>>>> Sent: Tuesday, October 25, 2011 9:40 AM >>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>> Subject: Re: [Pharo-project] startup errors >>>>> >>>>> On 24 October 2011 11:40, Andrea BrÃ¼hlmann <a.bruehlmann(a)netstyle.ch> >>>>> wrote: >>>>> >>>>>> It seems that pharo 1.3 introduced that the image quits if an error >>>>>> happens >>>>>> during startup. What are the reasons for this? >>>>>> >>>>>> >>>>> The reasons are simple: >>>>> if image fails to startup properly, there are no way to tell, if some >>>>> services initialized properly or not (UI is one of them), >>>>> and so, there are no any guarantees that image could run safely. >>>>> So, the best thing which you can do is to write error to log and >>>>> quit. >>>>> >>>>> This is because startup manager knows what to start-up and in what >>>>> order, but it doesn't knows, how critical a given service for >>>>> properly >>>>> running the whole image. Therefore, if you don't handle startup >>>>> errors >>>>> in your service code, a startup manager has no other choice , but >>>>> just >>>>> leave to OS. >>>>> >>>>> >>>>> >>>>>> Or what's the state of the email below? >>>>>> >>>>>> Andrea >>>>>> >>>>>> >>>>>> Camillo Bruni schrieb: >>>>>> >>>>>>> While working on Coral we encountered a rather annoying behavior of >>>>>>> pharo >>>>>>> images when starting up. >>>>>>> >>>>>>> We wanted to check if we can debug the CoralScriptLoader, but of >>>>>>> corse >>>>>>> since this happens at image startup time this is not a good ideaâ¦ >>>>>>> HOWEVER we >>>>>>> were no longer able to run the image as it immediately crashes >>>>>>> during >>>>>>> the >>>>>>> startup. >>>>>>> >>>>>>> Now I wonder if it would make sense to add a couple of on:do: in >>>>>>> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the >>>>>>> startup >>>>>>> scripts and then only show them after all other startupListItems >>>>>>> are >>>>>>> processed. >>>>>>> >>>>>>> All in all the behavior would not much differ from what is going on >>>>>>> right >>>>>>> now, but would prevent stupid users like me from losing a whole >>>>>>> image. >>>>>>> >>>>>>> camillo >>>>>>> >>>>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> -- >>> AB | ANDREA BRÃHLMANN Â· SOFTWARE ENGINEER >>> | NETSTYLE Â· TERRASSENWEG 18 Â· CH-3012 BERN >>> | TEL +41 31 356 42 54 Â· FAX +41 31 356 42 51 >>> | WWW.NETSTYLE.CH Â· A.BRUEHLMANN(a)NETSTYLE.CH >>> >>> >>> >> >> >> >> > > >

Jan. 16, 2012

Re: [Pharo-project] [Iliad] [ANN] Amber Smalltalk 0.9.1 is out!

by laurent laffont

Nice work guys ! Laurent On Mon, Jan 16, 2012 at 1:06 AM, Nicolas Petton <petton.nicolas(a)gmail.com>wrote: > About 4 moons have passed and Amber - the Smalltalk for the web - has > during that time moved forward quite a lot. Since the 0.9 release back > in september we have made about 250 commits and closed 52 issues of > about 75 reported during these months. > > Now with over 43 forks on github and more than 230 followers the > project: > > http://www.amber-lang.net > > ...is live and kicking! > > A lot of cool stuff is being done in those forks and not in the master > repository, like for example the gaming framework called Ludus by > Bernat > Romagosa: > > https://github.com/bromagosa/amber/tree/ludus > > ...or Ambrhino by Stefan Krecher - Amber running in Rhino: > > https://github.com/StefanKrecher/Ambrhino > > So, why would you take a look at Amber? > > In our opinion Amber is perfectly positioned for the HTML5 onslaught > and > the explosion of all-things-javascript like for example Nodejs. > > Amber plays very well with others and can seamlessly use Javascript > libraries! It's a *real* Smalltalk, the environment is all there > including Workspace, Transcript, Browser, > senders/implementors/references to class, TestRunner, Inspectors, code > editing with syntax coloring and a Debugger. There is no image or > interpreter, all compilation is incremental. > > JavaScript is quite a broken language with lots of traps and odd > quirks. > It is the assembler of the Internet and we love it for that, but we > don't want to write applications in it. Smalltalk is immensely cleaner, > both syntactically and semantically with a simple class model and a > lightweight syntax for closures. It is in many ways a perfect match for > the Good Parts of JavaScript. > > And having a true live interactive incremental development environment > where you can build your application directly in the browser is > unbeatable... > > > Below follows a summary of the major changes since release 0.9. We hope > you join us in developing Amber and having fun! Fork at github, join in > #amber-lang on freenode and hop onto the mailing list. > > regards, Nicolas & GÃ¶ran ...and a BIG thanks to everyone that are > involved in the project! > --------------------------------------------- > > Here's a summary of changes since the 0.9 release: > > - 80 new unit tests written > - 52 issues fixed > - All classes in Kernel-Objects, Kernel-Classes and Kernel-Methods has > been documented > - New documentation framework (see > http://amber-lang.net/documentation.html) > - Better class organisations, "Kernel" package split into several > packages > - First class packages have replaced class categories > - Internet Explorer 7+ compatibility > - New Announcement framework ported from Pharo > - New console-based REPL written in Amber using node.js > - Symbol class implemented together with object identity and #== > - New OrderedCollection and Set implementation > - Dictionary can now have any kind of object as keys. String-key > dictionary has been renamed HashedCollection > - New TwitterWall example > - Improved HTML Canvas, now compatible with IE7 > - Improved JSObjectProxy for seemless JavaScript objects access from > Amber > - No more jQuery binding. Amber is fully capable of sending messages to > JavaScript objects > > >

Jan. 16, 2012

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

by Sven Van Caekenberghe

+100 On 16 Jan 2012, at 02:44, Jimmie Houchin wrote: > 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