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

[Pharo-project] Fwd: [INRIAGforge] Monday 26th October 2009 : scheduled service downtime

by StÃ©phane Ducasse

Begin forwarded message: > From: <noreply(a)gforge.inria.fr> > Date: October 23, 2009 3:40:36 PM GMT+02:00 > To: stephane.ducasse(a)inria.fr > Subject: [INRIAGforge] Monday 26th October 2009 : scheduled service > downtime > > > On Monday 26th October 2009, from 18:30 to 22:00 the site and all > associated services will be unavailable due to maintenance > operations on the electrical supply. > > A reply to this announce will signal the end of the maintenance. > > We apologize for any inconvenience. > > Cordially, > > -- > The InriaGforge Team > > >

Oct. 23, 2009

Re: [Pharo-project] Finalization question

by Schwab,Wilhelm K

Sig, I think I am starting to understand. One thing though: WeakRegistry is a singleton customized to be part of the finalizer?? Not sure I like that. The name is too generic for the task. If I am indeed following, it sounds as though what Dolphin does with a flag on the expired object, Pharo does using a shallow copy of or other executor for the expired object. Does that sound like a reasonable paraphrasing? I am not sure which design I prefer, but I should be able to fake up an appropriate #beUnfinalizable to make my code happy on Pharo. Thanks!! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Friday, October 23, 2009 1:49 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Finalization question a rough analogy is something like that: Object>>beFinalizable "A shallow copy of the receiver will receive a #finalize message, once the receiver become garbage" WeakRegistry default add: self 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.

Oct. 23, 2009

Re: [Pharo-project] #1339 - ODBC crashes vm

by Schwab,Wilhelm K

Correction, I reported the problem, but anyone trying to use ODBC on Pharo will have a bad day until we fix something. Whether or not a bug lives in Pharo is of less interest to potential users (and to us!) than is having working code. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Friday, October 23, 2009 8:21 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] #1339 - ODBC crashes vm 2009/10/22 Henrik Johansen <henrik.s.johansen(a)veloxit.no<mailto:henrik.s.johansen@veloxit.no>> On Oct 20, 2009, at 4:16 37PM, Mariano Martinez Peck wrote: On Tue, Oct 20, 2009 at 8:06 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no<mailto:henrik.s.johansen@veloxit.no>> wrote: This one is caused by an initialization bug of some sort, the byteSizes of ODBC-structs are incorrect. In short, the solution is to do: ExternalStructure allSubclassesDo: [:each | each compileFields] after you load a package which defines ExternalStructure subclasses (like ODBC does). Hi Henrik! Nice to see you arround ;) In SqueakDBX I use FFI, I have subclasses of ExternalStructure and I don't remember having to do that. The only thing I do in those subclasses is to implement a class side method initialize like this: initialize super initialize. self defineFields And then, if you see defineFields you will se that at the end, it does a compileField... You can see defineFields in FFI documentation: http://wiki.squeak.org/squeak/2426 So, in my opinion a better solution may be this. What do you think ? Cheers Mariano Errr, so in conclusion, you didn't do exactly what I did, but something else which results in doing exactly the same, but in addition define accessors for the fields. So you did have to do that, even though you don't remember it. :P I think there there was a misunderstood. The one who has the problem was Schwab,Wilhelm Here's the reasons why I feel the solution you found, by itself, does not constitute a good solution: - If you DON'T remember to do it, the image of people loading your project might crash silently. - Neither FFI itself nor ODBC has remembered to do so (it's done in the loadFFI script in ScriptLoader) - Debugging it if you haven't read some arbitrary wiki-page was a real pain (partly because it doesn't crash as soon as the error is made) - Even you, who had actually read the wikipage, didn't make the association to this issue. I dont understand. In SqueakDBX (not ODBC) I have never had to send the message defineFields. It is sent by the class side initialize. So, I don't forget it. It is automatically. When you download SqueakDBX from Monticello, that's is done. A couple of alternative approaches: a) - Returning an error if a basicSize request would return 0 informing that fields have not been properly initialized (Or silently doing a recompile) b) Wait for MC1.6's atomic loader so you can be sure the fields method is compiled when a new external structure is installed :) c) Don't store into compiledSpec if fields is empty, on the presumption it will not be used until fields has been defined. (This won't actually work, as loading from MC will only execute class initialization only if class initialize method is defined in package being loaded (store works the same), but: d) - Do a compileFields: call in ExternalStructure>>initialize, and instead create a createAccessors method which can be overridden if necessary. ) a) and c) will both suffer from the issue that if you load/merge a newer version with additional fields defined, you get the same flaky behaviour as is experienced now. b) is probably some time off in the future, depending on when someone gets the time to implement trait support. a), but without the silent recompile and a helpful error message might be the best short-term option, since it'd remind authors to add class initialize-methods, and tell a user what to do if they've forgotten to do so instead of crashing the image. I've attached a changeset implementing c) to the issue. You forgot to upload the changeset ;) Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2009

Re: [Pharo-project] VNC (RFB) problem (2nd attempt)

by Dennis Schetinin

2009/10/17 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > > > > > Using pharo1.0-10466-BETAweb09.10.1 + > > RFB-DamienCassou.28 > > > (still the latest): the image stops to respond after > > closing > > > connection remotely. Stopping the server leaves > > image ok. > > > > > > > I can't reproduce it on a PharoCore 10470 image. > > ... > > > > I can't reproduce it on PharoCore or > > pharo1.0-10466-BETAweb09.10.1 > > > > And I have the same problem with this image too. So, the problem can > > be in my VNC client or perhaps in VM... I'll try to check both > > variants. Will be thankful for more ideas. > > > Thank you for your help very much. > Yes, try other clients. I have very distinct results (in video quality) > by using different clients. > Using the same image I still have the same problem with different clients running the server on (my own) Windows and has no problems on our (web-hosting) CentOS. So the problem is in VM or some kind of interaction with Windows... -- Dennis Schetinin

Oct. 23, 2009

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

by Mariano Martinez Peck

On Fri, Oct 23, 2009 at 4:43 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > 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? > Yes! I have no problem to do it. Right now, I will translate one of the Pharo By Example (1) chapters to Spanish. So, I will be familiar PBE and the .tex of it. Our website has a lot of documentation, so, I think I can get stuff from there as an start. What do you think? who is the one that is leading PBE2 ?

Oct. 23, 2009

Re: [Pharo-project] Thread-safe collections

by Schwab,Wilhelm K

Stef, With no disrespect to Sig's opinions, I'm glad to hear that. I very quickly cobbled together a class called SharedLookupTable, and have no problems making it (suitably debugged) available. Now it's time for me to kick your ass a little, to coin a phrase :) Monticello is pretty good at what it does, but I sense the things it does not do interfering with good decision making. The class ended up in my Dolphin compatibility package, in part because it belongs there, though it really should be separate so I can easily release it and people would be able to get it w/o having to accept other ideas they might not want. But it went in the compatiblity package so I would not have to mess around with another package. Saving them is a pain; loading them into a new image is a pain. Saving: the interface works well once understood, and the features it offers should never go away. However, either by script or by multiple selection, it would be nice to provide a comment to be applied to everything to be saved "now" vs. having to be prompted for it, then have the list scroll, then have to click away another window. Do that 30 times and it starts to get old. Loading: I spent a chunk of yesterday trying to build an RC1 image. Doing so revealed that my script-loader for script-loader does not validate package names. I had one build attempt come to a halt over case-sensitivity; I do not mind that. What I mind is that the particular case mix in question was more or less forced on me by a typo of mine. If MC were better about offering choices when they apply, I might not have typed it that way. I realize that Gofer is coming, and it might fix a lot of this. The ideas above are probably not new, but I list them just in case. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Friday, October 23, 2009 2:46 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Thread-safe collections 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 _______________________________________________ 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] #1339 - ODBC crashes vm

by Mariano Martinez Peck

2009/10/22 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > On Oct 20, 2009, at 4:16 37PM, Mariano Martinez Peck wrote: > > > > On Tue, Oct 20, 2009 at 8:06 AM, Henrik Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> This one is caused by an initialization bug of some sort, the >> byteSizes of ODBC-structs are incorrect. >> >> In short, the solution is to do: >> ExternalStructure allSubclassesDo: [:each | each compileFields] >> after you load a package which defines ExternalStructure subclasses >> (like ODBC does). >> >> > Hi Henrik! Nice to see you arround ;) > > In SqueakDBX I use FFI, I have subclasses of ExternalStructure and I don't > remember having to do that. The only thing I do in those subclasses is to > implement a class side method initialize like this: > > initialize > super initialize. > self defineFields > > > And then, if you see defineFields you will se that at the end, it does a > compileField... > You can see defineFields in FFI documentation: > http://wiki.squeak.org/squeak/2426 > > So, in my opinion a better solution may be this. What do you think ? > > Cheers > > Mariano > > > Errr, so in conclusion, you didn't do exactly what I did, but something > else which results in doing exactly the same, but in addition define > accessors for the fields. > So you did have to do that, even though you don't remember it. :P > I think there there was a misunderstood. The one who has the problem was Schwab,Wilhelm > Here's the reasons why I feel the solution you found, by itself, does not > constitute a good solution: > - If you DON'T remember to do it, the image of people loading your project > might crash silently. > - Neither FFI itself nor ODBC has remembered to do so (it's done in the > loadFFI script in ScriptLoader) > - Debugging it if you haven't read some arbitrary wiki-page was a real pain > (partly because it doesn't crash as soon as the error is made) > - Even you, who had actually read the wikipage, didn't make the association > to this issue. > > I dont understand. In SqueakDBX (not ODBC) I have never had to send the message defineFields. It is sent by the class side initialize. So, I don't forget it. It is automatically. When you download SqueakDBX from Monticello, that's is done. > A couple of alternative approaches: > a) - Returning an error if a basicSize request would return 0 informing > that fields have not been properly initialized (Or silently doing a > recompile) > b) Wait for MC1.6's atomic loader so you can be sure the fields method is > compiled when a new external structure is installed :) > c) Don't store into compiledSpec if fields is empty, on the presumption it > will not be used until fields has been defined. > (This won't actually work, as loading from MC will only execute class > initialization only if class initialize method is defined in package being > loaded (store works the same), but: > d) - Do a compileFields: call in ExternalStructure>>initialize, and instead > create a createAccessors method which can be overridden if necessary. ) > > a) and c) will both suffer from the issue that if you load/merge a newer > version with additional fields defined, you get the same flaky behaviour as > is experienced now. > b) is probably some time off in the future, depending on when someone gets > the time to implement trait support. > a), but without the silent recompile and a helpful error message might be > the best short-term option, since it'd remind authors to add class > initialize-methods, and tell a user what to do if they've forgotten to do so > instead of crashing the image. > > I've attached a changeset implementing c) to the issue. > > You forgot to upload the changeset ;) > Cheers, > Henry > > > > > _______________________________________________ > 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 Schwab,Wilhelm K

Stef, Far be it from me to kick you anywhere, but IMHO a local Seaside server is a very nice OPTION to have; I strongly disagree with those who have suggested the Polymorph, host widgets, etc. are a waste of time by comparison. We need both. One niche where local-only Seaside is a great idea is to provide a configuration GUI for a service. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Friday, October 23, 2009 2:41 AM To: Pharo-project(a)lists.gforge.inria.fr; rick(a)m45.us Subject: Re: [Pharo-project] Starting out: db and gui recommendation 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 _______________________________________________ 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] Shared directories: The bug is quicker than the eye

by Schwab,Wilhelm K

Stef, If you can think of any ways to reproduce it, let me know - I have reliably bad network connectivity at your service :) Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Friday, October 23, 2009 2:39 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Shared directories: The bug is quicker than the eye 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 _______________________________________________ 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] [update 1.1] #11013

by StÃ©phane Ducasse

11013 ----- - Issue 1334: [Squeak trunk] New tests for String format - Issue 1333: [squeak trunk] Add timeProfile to BlockClosure - Issue 1335: [Squeak trunk] Faster shuffle - Issue 1136: DejaVu strinkeFonts render ascii character in WideStrings as black boxes - Issue 1305: Deleting morphs from the yellow button menu - Issue 1303: MNU #who when decompiling Fix the sender of #who with method from trunk (tfel) I don t know if this test is still relevant: = #unknown ifTrue: [] Or if it should be replaced with: ifNil: [] See http://code.google.com/p/pharo/issues/detail?id=1303

Oct. 23, 2009