- Pharo-dev - lists.pharo.org

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

by John M McIntosh

Well the rate of change in the file i/o plugin is rather glacial. The write code on unix systems is below, you'll note the magic, "lastOp", "position" and a seek or two to ensure where you thought you wrote to, is where you wrote to. Also setSize() is busy updating the file size, which later fools you if you are reading from a shared file because you don't actually ask for the real file size, you get back the size we think it was in the past. However the fwrite() does return the bytes written and there is a check to see if it matches expectations, and if not this it setups the primitive call to fail. So if the write failed it would run the primitive failure call smalltalk code what that does, or who handles the exception raised if any, I have no idea... size_t sqFileWriteFromAt(SQFile *f, size_t count, char* byteArrayIndex, size_t startIndex) { /* Write count bytes to the given writable file starting at startIndex in the given byteArray. (See comment in sqFileReadIntoAt for interpretation of byteArray and startIndex). */ char *src; size_t bytesWritten; squeakFileOffsetType position; FILE *file; if (!(sqFileValid(f) && f->writable)) return interpreterProxy->success (false); file= getFile(f); if (f->lastOp == READ_OP) fseek(file, 0, SEEK_CUR); /* seek between reading and writing */ src = byteArrayIndex + startIndex; bytesWritten = fwrite(src, 1, count, file); position = ftell(file); if (position > getSize(f)) { setSize(f, position); /* update file size */ } if (bytesWritten != count) { interpreterProxy->success(false); } f->lastOp = WRITE_OP; return bytesWritten; } On 2009-10-23, at 12:43 PM, Schwab,Wilhelm K wrote: > John, > > That sounds badly, badly, broken. Is it "only" #flush that suffers, > or will any of the I/O fail silently? > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo- > project-bounces(a)lists.gforge.inria.fr] On Behalf Of John M McIntosh > Sent: Friday, October 23, 2009 1:57 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Shared directories: The bug is quicker > than the eye > > If you invoke the flush primitive then it does this on unix/linux/ > mac- osx/iPhone http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa… > & > http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa… > > sqInt sqFileFlush(SQFile *f) { > /* Return the length of the given file. */ > > if (!sqFileValid(f)) return interpreterProxy->success(false); > fflush(getFile(f)); > return 1; > } > > On windows it does > http://msdn.microsoft.com/en-us/library/aa364439(VS.85).aspx > > sqInt sqFileFlush(SQFile *f) { > if (!sqFileValid(f)) FAIL(); > /* note: ignores the return value in case of read-only access */ > FlushFileBuffers(FILE_HANDLE(f)); > return 1; > } > > I'll note the api doesn't actually check for errors, give feedback > or whatever. > *cough* it could be failing and give you a clue, but you would need > to resort to FFI to do the file system calls to get the data to > visualize, or build your own VM with that returns the result. > > > > On 2009-10-22, at 5:31 PM, 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 > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 23, 2009

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

by Schwab,Wilhelm K

John, That sounds badly, badly, broken. Is it "only" #flush that suffers, or will any of the I/O fail silently? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John M McIntosh Sent: Friday, October 23, 2009 1:57 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Shared directories: The bug is quicker than the eye If you invoke the flush primitive then it does this on unix/linux/mac- osx/iPhone http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa… & http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa… sqInt sqFileFlush(SQFile *f) { /* Return the length of the given file. */ if (!sqFileValid(f)) return interpreterProxy->success(false); fflush(getFile(f)); return 1; } On windows it does http://msdn.microsoft.com/en-us/library/aa364439(VS.85).aspx sqInt sqFileFlush(SQFile *f) { if (!sqFileValid(f)) FAIL(); /* note: ignores the return value in case of read-only access */ FlushFileBuffers(FILE_HANDLE(f)); return 1; } I'll note the api doesn't actually check for errors, give feedback or whatever. *cough* it could be failing and give you a clue, but you would need to resort to FFI to do the file system calls to get the data to visualize, or build your own VM with that returns the result. On 2009-10-22, at 5:31 PM, 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 -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ 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] #11015

by StÃ©phane Ducasse

11015 ----- 1272 follow up part 3 Last part of cleanup, remove basicShallowCopy Issue 1338: HostWindowTests>>testOne is failing in Windows

Oct. 23, 2009

Re: [Pharo-project] About built in plugins

by John M McIntosh

Well because if it takes more than a couple of minutes, many minutes of messing about to build the xcode project to allow you to build a plugin as an external plugin, so no-one has bothered. However if you want to override the default behaviour with a B3DAcceleratorPlugin which has different logic you just stick your pretty B3DAcceleratorPlugin in the squeak vm.app/Resource folder. On 2009-10-23, at 1:14 AM, Fernando olivero wrote: > 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 > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 23, 2009

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

by John M McIntosh

If you invoke the flush primitive then it does this on unix/linux/mac- osx/iPhone http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa… & http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPa… sqInt sqFileFlush(SQFile *f) { /* Return the length of the given file. */ if (!sqFileValid(f)) return interpreterProxy->success(false); fflush(getFile(f)); return 1; } On windows it does http://msdn.microsoft.com/en-us/library/aa364439(VS.85).aspx sqInt sqFileFlush(SQFile *f) { if (!sqFileValid(f)) FAIL(); /* note: ignores the return value in case of read-only access */ FlushFileBuffers(FILE_HANDLE(f)); return 1; } I'll note the api doesn't actually check for errors, give feedback or whatever. *cough* it could be failing and give you a clue, but you would need to resort to FFI to do the file system calls to get the data to visualize, or build your own VM with that returns the result. On 2009-10-22, at 5:31 PM, 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 -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Oct. 23, 2009

[Pharo-project] [update 1.1] #11014

by StÃ©phane Ducasse

11014 ----- 1272 followup part one and two Perform some additional cleaning after integration of http://code.google.com/p/pharo/issues/detail?id=1272

Oct. 23, 2009

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

by Rick Morrison

Thanks for all the responses. They have caused me to rethink a couple of things already. Sqlite is a holdover from thinking about a .Net version of this app. I just need to persist my data. Something like Magma should be fine. I had been looking at Sqlite as an embedded database since I didn't need (or don't want to make the user manage) a database server. I ran the UIThemes examples and I like the look. But I might just use the browser and a local Seaside server to give me a chance to learn more about web programming. It doesn't have to be a desktop app but my wife, who is has a problem to be solved and is my customer, says she would not put the data on the web. I will consider if some of the less personal data could be web-based (and then more universally accessible) and some data restricted to local storage. A hybrid if you will. I have to admit that I stretched a little bit when I said "I am a Java & .Net application programmer", "was" is almost more correct now. Like so many, I do more project management now and really miss the coding. I've been reading "The Passionate Programmer" and I'm following his advice to learn something very different from what I know now. Thanks again. Now off to review some of the things you have brought to my attention. Rick On Thu, Oct 22, 2009 at 9:30 PM, Rick Morrison <rick(a)m45.us> wrote: > I am a Java & .Net application programmer who has flirted with Smalltalk > for a long time without doing the > > Thanks for any help, > Rick >

Oct. 23, 2009

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

by Esteban Lorenzano

On 2009-10-23 02:08:20 -0200, Mariano Martinez Peck <marianopeck(a)gmail.com> said: > > > 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 :) > 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'm also using xulrunner (runing seaside apps) with very good results, and that gives me better control of "window close" event... and the app looks much more "native" that unsing a regular browser. Cheers, Esteban

Oct. 23, 2009

[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