October 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Improve pharo modularity: a first step

by StÃ©phane Ducasse

Jannik may be we should have PackageCore PackageTest PackageSetting PackageExamples in the future On Oct 23, 2009, at 9:02 AM, Laval Jannik wrote: > Hi all, > > I would like to improve the modularity of packages in pharo. > > A first simple thing that I see, is methods "example" use a lot of > things in the system. > And create cycles between packages. > > So, I propose to create a new package named "Examples" and put in it > all methods named "example2"... > > > Jannik > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2009

[Pharo-project] About built in plugins

by Fernando olivero

Hi, just curious..does somebody know why 'B3DAcceleratorPlugin' is built in into the mac vm ? SmalltalkImage current listLoadedModules #('B3DAcceleratorPlugin 2 March 2009 (i)' 'SocketPlugin 2 March 2009 (i)' 'FloatArrayPlugin 2 March 2009 (i)' 'B2DPlugin 2 March 2009 (i)' 'InternetConfigPlugin 2 March 2009 (i)' 'FT2Plugin 24 April 2007 (e)' 'MacMenubarPlugin 2 March 2009 (i)' 'LargeIntegers v1.5 2 March 2009 (i)' 'BitBltPlugin 2 March 2009 (i)' 'SecurityPlugin 2 March 2009 (i)' 'FilePlugin 2 March 2009 (i)' 'DropPlugin 2 March 2009 (i)' 'MiscPrimitivePlugin 2 March 2009 (i)') Saludos, Fernando

Oct. 23, 2009

Re: [Pharo-project] [squeak-dev] Re: Issue with traits

by Marcus Denker

On 21.10.2009, at 11:13, Marcus Denker wrote: > > On 21.10.2009, at 09:41, Adrian Lienhard wrote: > >> I've fixed this issue in Pharo a couple of months ago. >> CompiledMethods >> are not shared anymore, so methodClass returns the expected class. At >> the time I implemented traits (2004?), there were no method >> properties >> and hence sharing compiled methods worked -- of course except for >> super sends in which case the method was always recompiled (so the >> answer to Andreas' question below is b)). >> > > We did a small paper for this years ESUG that describes the changes. > It will be online at esug.org soon with all the other papers. > Here is the pdf: http://marcusdenker.de/publications/Duca09bTraitsAPI.pdf Marcus -- Marcus Denker -- marcus(a)2denker.de http://www.2denker.de

Oct. 23, 2009

Re: [Pharo-project] Improve pharo modularity: a first step

by Igor Stasenko

2009/10/23 Laval Jannik <jannik.laval(a)gmail.com>: > Hi all, > > I would like to improve the modularity of packages in pharo. > You might want to look at it: http://www.comtalk.cz/Squeak/98 > A first simple thing that I see, is methods "example" use a lot of > things in the system. > And create cycles between packages. > > So, I propose to create a new package named "Examples" and put in it > all methods named "example2"... > Just a warning: if you gather all examples irrespectible to packages, you will create a single package with a lot of dependencies. > > Jannik > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 23, 2009

Re: [Pharo-project] Thread-safe collections

by StÃ©phane Ducasse

I would really like to see some packages getting implementing around the idea of a couple of robust and well tested thread safe collections. Stef On Oct 23, 2009, at 2:16 AM, Schwab,Wilhelm K wrote: > Sig, > > One can always construct examples in which protecting the entire > loop is the better option. That's not the scenario of interest. > Just as shared queues are useful, shared sets and dictionaries have > value for sporadic access scenarios. Doing it your way, everyone > writes their own incompletely protected (read buggy/dangerous) ad- > hoc implementations of these common collections. > > I favor having solid implementations that are complete and as > correct as we can get them, leaving people to optimize as you > suggest when it makes sense to do so. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko > Sent: Thursday, October 22, 2009 5:23 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Thread-safe collections > > 2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: >> Hello all, >> >> I just looked around for thread-safe collections, and found nothing >> that looks like a shared dictionary. The squeak-dev archives >> contain the obligatory newbie posts (wanting all collections to be >> thread safe) and the expected replies, some of which are overly >> dismissive of the idea. Something that protects things like >> #at:ifAbsentPut: and friends is _really_ useful. Am I missing an >> existing implementation? >> > > Imo, there's only one shared collection which is useful - shared > queue. :) If you need more kinds of thread-safe collections, it > probably indicating that the concurrent code (or model) which you > designed is in pretty bad shape. > > Just compare two following snippets: > > 1 to: 100 do: [:i | collection threadSafeAt: i put: something]. > > and: > > semaphore critical: [ 1 to: 100 do: [:i | collection at: i put: > something] ]. > > What you think, which one is better? > > >> Bill >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2009

Re: [Pharo-project] Starting out: db and gui recommendation

by StÃ©phane Ducasse

On Oct 23, 2009, at 6:08 AM, Mariano Martinez Peck wrote: > > > 2009/10/22 Rick Morrison <rick(a)m45.us> > I am a Java & .Net application programmer who has flirted with > Smalltalk for a long time without doing the "deep dive" to really > understand it. Pharo and Seaside are making me think that > everything is coming together now for another try. That and some > micro-ISV ambitions to give me a real reason to write some code > outside of work. > > > Welcome!!! I hope you enjoy this wonderful world ;) > > For my type of project I really need a db package and a gui > package. That leads to the questions: > 1. Right now, is SqeakDBX my best choice for a db interface? Sqlite > is my db of choice for the project I have in mind. > > Of course!!! hahahahaha (I am one of the SqueakDBX authors). But > it is a joke. There are several persitence alternatives. You can see > this link: > http://www.seaside.st/documentation/persistence > There others nice solutions like Magma, CouchDB and TokyoTyrant, > etc. The good thing is that you have several approaches. There must > be one that fits better your needs. > BTW, SqueakDBX works perfect with Sqlite3 in Linux, Mac and Windows. > Which OS do you want to use? You can even create (I can help you if > you want) a seaside one-click with the Sqlite3 and OpenDBX dlls. So, > this type of app is very "portable": just unzip and double click :) mariano it would be nice if you could start to write something on it. May be we could turn that into a chapter for the pharo v 2 book? > For more details about SqueakDBX you can see http://www.squeakdbx.org/ > > 2. For the UI, I've been reading about the choices and I'm having a > hard time finding a currently supported project. Do I go with > polymorph by default? > > For the UI, what about "self-hosting" a Seaside instance and doing > the UI in the browser? Ie, the app starts a Seaside server and > opens a browser window pointed at the apps main window (home page). > Can that be done? Is it a good idea? > > > Yes, I saw a lot of people doing this. They have a one click seaside > image where you just do a double click and then open the browser > with localhost > And as I told you, you can have sqlite3 inside that zip. > On there other hand, there is a very interesting project that let > you build "heavy client apps" with Polymorph using a palette and > drag and drop. You can see a video here: http://www.youtube.com/watch?v=CHbc1t83fEI > > I hope you can give me some direction. I like the direction of > Pharo and Seaside is just plain cool. I want to do this to get my > head outside the coding box I'm kind of stuck in. And have some fun. > > > There are 2 new books if you want: one for seaside and one for pharo: > > - http://www.pharobyexample.org/ > - http://book.seaside.st/book > > > Thanks for any help, > > You are wolcome! > > Rick > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2009

Re: [Pharo-project] Starting out: db and gui recommendation

by StÃ©phane Ducasse

Hi rick welcome! > I am a Java & .Net application programmer who has flirted with > Smalltalk for a long time without doing the "deep dive" to really > understand it. Pharo and Seaside are making me think that > everything is coming together now for another try. That and some > micro-ISV ambitions to give me a real reason to write some code > outside of work. > > For my type of project I really need a db package and a gui > package. That leads to the questions: > 1. Right now, is SqeakDBX my best choice for a db interface? Sqlite > is my db of choice for the project I have in mind. > 2. For the UI, I've been reading about the choices and I'm having a > hard time finding a currently supported project. Do I go with > polymorph by default? If you need a desktop app yes. Else why not seaside directly? > For the UI, what about "self-hosting" a Seaside instance and doing > the UI in the browser? Ie, the app starts a Seaside server and > opens a browser window pointed at the apps main window (home page). > Can that be done? Is it a good idea? Yes! > I hope you can give me some direction. I like the direction of > Pharo and Seaside is just plain cool. I want to do this to get my > head outside the coding box I'm kind of stuck in. And have some fun. We want the same. :) Do not hesitate to kick our asses. The Smalltalk community got trapped into the "we invented the mouse" syndrome and we should really move again. Stef

Oct. 23, 2009

Re: [Pharo-project] Shared directories: The bug is quicker than the eye

by StÃ©phane Ducasse

I do not really know if this is related but yesterday I got a problem with a student saving MCZ files on usb disc. May be the OS was using a buffer but none of the files where wirtten there, when surprisingly the changes were saved. Stef On Oct 23, 2009, at 2:31 AM, Schwab,Wilhelm K wrote: > Hello all, > > I'm not sure what to make of this one. I just spent a couple of > hours trying to find the "leak" in an algorithm of mine. It was > reading roughly 1200 records, claiming to have processed all of > them, and yet writing only about 450 rows into an output text file. > One clue should have been that the number of output rows was > somewhat random; I did not fully appreciate that until I worked > around the problme. > > I tried an explicit #flush - no help. I looked for logic errors and > found none. The file was being written to a Windows hosted share > mounted by CIFS (which I am learning to view with contempt) from > Ubuntu 9.04. You can see where this is going: writing the file > locally gave the expected result. > > Any ideas on how one might further isolate the problem? My trust in > Windows is well known<g>; I have never liked shared directories; I > _really_ do not like CIFS as compared (reliability wise) to SMBFS; > the network between me and the server is in question too (long > story). All of that said, file support in Squeak, and hence so far > inherited by Pharo, is not the best code I have seen to date, so it > is easy to suspect too. Can one argue that since it worked locally, > Pharo is not the problem? > > The little bit that I know of cifs is not encouraging. It sounds as > though things moved from an easily killed process into the kernel > which shows an almost Windows-like unwillingness to shut down when > it cannot see servers. I have found numerous reports of problems > copying large files over cifs, and I have enountered them too. > > Bill > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2009

[Pharo-project] Improve pharo modularity: a first step

by Laval Jannik

Hi all, I would like to improve the modularity of packages in pharo. A first simple thing that I see, is methods "example" use a lot of things in the system. And create cycles between packages. So, I propose to create a new package named "Examples" and put in it all methods named "example2"... Jannik

Oct. 23, 2009

Re: [Pharo-project] Finalization question

by Igor Stasenko

2009/10/23 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sorry for the extra message. Â Outlook - need I say more? > > Hello all, > > I have started to port some of my code that relies on Dolphin's finalization. Â The idea is that one sends #beFinalizable to the object requiring finalization. Â Dolphin sets a flag on the object (in its header??) that the vm later notices. Â The end result is the object in question receives #finalize and cleans up its own mess; it can also "cheat death" but I doubt I have need for that level of control. > > My question is that the Squeak/Pharo design appears to be built on ObjetFinalizer instances that are associated with finalizable objects, each recording what to do when an object expires. Â If that's true, then I'm wondering why objects understand #finalize. Â That seems to conflict with #toFinalize:send:to:with:, which looks like it expects just enough information to do the cleanup for the expired object. > you can use #add:executor: and provide a custom executor for object. An ObjectFinalizer just a generic class provided for convenience. Anyways, all of this stuff ends up in WeakRegistry, so its a question of personal taste, what to use. Or, if you think you are hardcore, you can write own class which provides finalizatin services. Then you can add it to: WeakArray addWeakDependent: yourStuff. And at each GC cycle, when finalization process will awake, your object will receive #finalizeValues mesasge, where you free to choose what to finalize and how. > Any idea what I might be missing here or pointers to required reading? Â I found something from 2003 (Squeak 3.7) which might be out of date, or maybe I'm just working too late :) > > Bill > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Oct. 23, 2009