February 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3686 in pharo: Deprecate PseudoFileStream

by pharo＠googlecode.com

Status: Accepted Owner: guillerm...(a)gmail.com New issue 3686 by guillerm...(a)gmail.com: Deprecate PseudoFileStream http://code.google.com/p/pharo/issues/detail?id=3686 No comment, not usages, deprecation for you :).

Feb. 9, 2011

Re: [Pharo-project] new Cog VMs available

by Schwab,Wilhelm K

GREAT!!!!! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen [henrik.s.johansen(a)veloxit.no] Sent: Tuesday, February 08, 2011 8:38 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] new Cog VMs available On 09.02.2011 02:31, Schwab,Wilhelm K wrote: > New vms that read cog images - as in cog is no longer a one-way street? That would make it safer/easier to test. Yes. Cheers, Henry

Feb. 9, 2011

Re: [Pharo-project] Status of Alien

by Schwab,Wilhelm K

Eliot, I'm impressed :) To say that I truly understand would be dishonest, but I think I more or less get it. How is the binding of a Process to a thread done - I guess I am really asking what it looks like in code? One choice would be class side messages to ProcessScheduler or similar that return handles to or wrappers for the threads (#gui and #newThread come to mind), and those could be provided to a new process to bind it. Am I close? It sounds like a really nice solution to the problem. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Tuesday, February 08, 2011 8:57 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien On Tue, Feb 8, 2011 at 5:45 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Eliot, No lack of patience implied: just mentioning some things that I have picked up as off in the future and that would make us all stronger. Re the calls on OS threads, that is GREAT news. What strategy are you using to assign calls to the threads? I ask because there is a tradeoff between using a pool and taking what is ready to go, and coping with thread affinity. Example: OpenSSL is "easy" to call if one uses blocking calls and simply moves them out of the main thread (at least it worked for me on Dolphin). When I did this, I had to write a wrapper DLL to combined calls (connect, read, send, etc.) and checks for error status because otherwise, Dolphin would typically use different threads for the calls and the error test call was meaningless. IIRC, now they always use the same OS thread for any given Smalltalk Process - I think. There is no pool. Instead, arbitrary threads can run the VM, but only one at a time. So the strategy to control calls is to decide which processes are bound to which threads. A new Smalltalk process can be executed by any thread. There is a well-known thread id for "the GUI thread" and it may be necessary to have more. So to arrange that a call is made on the GUI thread one arranges that the cal is made from a Smalltalk process that is bound to the GUI thread. To arrange that calls are made form some specific thread once again one binds one or more processes to that thread and makes calls from those processes. The VM's Smalltalk scheduler is modified to do a thread switch when a process switch is made to a process bound to other than the current thread (i.e. it is now a classic two-level scheduler). Hence scheduling semantics don't change; it is still a real-time scheduler that always runs the highest-priority runnable Smalltalk process. Its just that under the covers an implicit thread switch might also occur when a process switch occurs. Make sense? best Eliot I fixed a few more things that have been pinning me to my hacked vms, so I will hopefully be able to more easily experiment. I will look around for Alien on Linux and give it a try if I find it. I am also looking forward to running my "real" images through Cog. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Eliot Miranda [eliot.miranda(a)gmail.com<mailto:eliot.miranda@gmail.com>] Sent: Tuesday, February 08, 2011 11:19 AM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Cc: Squeak Virtual Machine Development Discussion Subject: Re: [Pharo-project] Status of Alien On Tue, Feb 8, 2011 at 4:16 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu><mailto:bschwab@anest.ufl.edu<mailto:bschwab@anest.ufl.edu>>> wrote: Torsten, I have been under the impression that it has never worked on Linux - it would be great to be wrong on that. Does anyone have Alien on Linux waiting for someone to try it? I would be very surprised if it didn't work. We at least use the data manipulation side of things routinely at Teleplace. One thing slowing my search for FFI/Alien improvements has been that I was initially dependent on some vm modifications that I made. Some off-line correspondence with Dave Lewis and the benefit of some time might have yielded a solution that will let me return to stock vms. I need to integrate my new callback support and the ReentrantFFIPlugin into the standard interpreter as soon as possible. The ReentrantFFIPlugin provides compatibility with the old squeak FFI plugin but also allows aliens to be passed as arguments, at least to the extent of passing Alien Callbacks. This means its possible to discard the Alien callout support and use the FFI instead (but just to reiterate to keep the Alien data representation and callback facilities). The project for the next few weekends has to be harmonising the primitive set and functionality of Cog and the standard interpreter now that the StackToRegisterMappingCogit looks complete. FFI has generally worked for me. I am doing a horrible job of handling double arrays, but I am at least able to use them. My "solution" makes assumptions about byte order and I have declare double* as void*. There was mention of extending FFI with callbacks. Given that capability, the only thing missing would then to be make calls on OS threads to avoid blocking the image (but blocking the calling Smalltalk Process for the duration of the call). I have this in prototype and want to release soon. But there is too much else going on right now. Patience please. best Eliot Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr><mailto:pharo-project-bounces@lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>>] On Behalf Of Torsten Bergmann [astares(a)gmx.de<mailto:astares@gmx.de><mailto:astares@gmx.de<mailto:astares@gmx.de>>] Sent: Tuesday, February 08, 2011 4:04 AM To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr><mailto:pharo-project@lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr>> Subject: [Pharo-project] Status of Alien What is the status of Alien. According to http://bugs.squeak.org/view.php?id=7475 there is no one who confirmed it working on Linux. Any news here? Any ideas on FFI/Alien successor? Thanks T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

Feb. 9, 2011

Re: [Pharo-project] Status of Alien

by Eliot Miranda

On Tue, Feb 8, 2011 at 5:45 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > Eliot, > > No lack of patience implied: just mentioning some things that I have picked > up as off in the future and that would make us all stronger. > > Re the calls on OS threads, that is GREAT news. What strategy are you > using to assign calls to the threads? I ask because there is a tradeoff > between using a pool and taking what is ready to go, and coping with thread > affinity. Example: OpenSSL is "easy" to call if one uses blocking calls and > simply moves them out of the main thread (at least it worked for me on > Dolphin). When I did this, I had to write a wrapper DLL to combined calls > (connect, read, send, etc.) and checks for error status because otherwise, > Dolphin would typically use different threads for the calls and the error > test call was meaningless. IIRC, now they always use the same OS thread for > any given Smalltalk Process - I think. > There is no pool. Instead, arbitrary threads can run the VM, but only one at a time. So the strategy to control calls is to decide which processes are bound to which threads. A new Smalltalk process can be executed by any thread. There is a well-known thread id for "the GUI thread" and it may be necessary to have more. So to arrange that a call is made on the GUI thread one arranges that the cal is made from a Smalltalk process that is bound to the GUI thread. To arrange that calls are made form some specific thread once again one binds one or more processes to that thread and makes calls from those processes. The VM's Smalltalk scheduler is modified to do a thread switch when a process switch is made to a process bound to other than the current thread (i.e. it is now a classic two-level scheduler). Hence scheduling semantics don't change; it is still a real-time scheduler that always runs the highest-priority runnable Smalltalk process. Its just that under the covers an implicit thread switch might also occur when a process switch occurs. Make sense? best Eliot > I fixed a few more things that have been pinning me to my hacked vms, so I > will hopefully be able to more easily experiment. I will look around for > Alien on Linux and give it a try if I find it. I am also looking forward to > running my "real" images through Cog. > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Eliot Miranda [ > eliot.miranda(a)gmail.com] > Sent: Tuesday, February 08, 2011 11:19 AM > To: Pharo-project(a)lists.gforge.inria.fr > Cc: Squeak Virtual Machine Development Discussion > Subject: Re: [Pharo-project] Status of Alien > > On Tue, Feb 8, 2011 at 4:16 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu > <mailto:bschwab@anest.ufl.edu>> wrote: > Torsten, > > I have been under the impression that it has never worked on Linux - it > would be great to be wrong on that. Does anyone have Alien on Linux waiting > for someone to try it? > > I would be very surprised if it didn't work. We at least use the data > manipulation side of things routinely at Teleplace. > > > One thing slowing my search for FFI/Alien improvements has been that I was > initially dependent on some vm modifications that I made. Some off-line > correspondence with Dave Lewis and the benefit of some time might have > yielded a solution that will let me return to stock vms. > > I need to integrate my new callback support and the ReentrantFFIPlugin into > the standard interpreter as soon as possible. The ReentrantFFIPlugin > provides compatibility with the old squeak FFI plugin but also allows > aliens to be passed as arguments, at least to the extent of passing Alien > Callbacks. This means its possible to discard the Alien callout support and > use the FFI instead (but just to reiterate to keep the Alien data > representation and callback facilities). The project for the next few > weekends has to be harmonising the primitive set and functionality of Cog > and the standard interpreter now that the StackToRegisterMappingCogit looks > complete. > > > FFI has generally worked for me. I am doing a horrible job of handling > double arrays, but I am at least able to use them. My "solution" makes > assumptions about byte order and I have declare double* as void*. > > There was mention of extending FFI with callbacks. Given that capability, > the only thing missing would then to be make calls on OS threads to avoid > blocking the image (but blocking the calling Smalltalk Process for the > duration of the call). > > I have this in prototype and want to release soon. But there is too much > else going on right now. Patience please. > > best > Eliot > > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto: > pharo-project-bounces(a)lists.gforge.inria.fr> [ > pharo-project-bounces(a)lists.gforge.inria.fr<mailto: > pharo-project-bounces(a)lists.gforge.inria.fr>] On Behalf Of Torsten > Bergmann [astares(a)gmx.de<mailto:astares@gmx.de>] > Sent: Tuesday, February 08, 2011 4:04 AM > To: pharo-project(a)lists.gforge.inria.fr<mailto: > pharo-project(a)lists.gforge.inria.fr> > Subject: [Pharo-project] Status of Alien > > What is the status of Alien. > According to > > http://bugs.squeak.org/view.php?id=7475 > > there is no one who confirmed it working on Linux. > > Any news here? Any ideas on FFI/Alien successor? > > Thanks > T. > -- > GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit > gratis Handy-Flat! http://portal.gmx.net/de/go/dsl > > > > >

Feb. 9, 2011

Re: [Pharo-project] Status of Alien

by Schwab,Wilhelm K

Eliot, No lack of patience implied: just mentioning some things that I have picked up as off in the future and that would make us all stronger. Re the calls on OS threads, that is GREAT news. What strategy are you using to assign calls to the threads? I ask because there is a tradeoff between using a pool and taking what is ready to go, and coping with thread affinity. Example: OpenSSL is "easy" to call if one uses blocking calls and simply moves them out of the main thread (at least it worked for me on Dolphin). When I did this, I had to write a wrapper DLL to combined calls (connect, read, send, etc.) and checks for error status because otherwise, Dolphin would typically use different threads for the calls and the error test call was meaningless. IIRC, now they always use the same OS thread for any given Smalltalk Process - I think. I fixed a few more things that have been pinning me to my hacked vms, so I will hopefully be able to more easily experiment. I will look around for Alien on Linux and give it a try if I find it. I am also looking forward to running my "real" images through Cog. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Eliot Miranda [eliot.miranda(a)gmail.com] Sent: Tuesday, February 08, 2011 11:19 AM To: Pharo-project(a)lists.gforge.inria.fr Cc: Squeak Virtual Machine Development Discussion Subject: Re: [Pharo-project] Status of Alien On Tue, Feb 8, 2011 at 4:16 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Torsten, I have been under the impression that it has never worked on Linux - it would be great to be wrong on that. Does anyone have Alien on Linux waiting for someone to try it? I would be very surprised if it didn't work. We at least use the data manipulation side of things routinely at Teleplace. One thing slowing my search for FFI/Alien improvements has been that I was initially dependent on some vm modifications that I made. Some off-line correspondence with Dave Lewis and the benefit of some time might have yielded a solution that will let me return to stock vms. I need to integrate my new callback support and the ReentrantFFIPlugin into the standard interpreter as soon as possible. The ReentrantFFIPlugin provides compatibility with the old squeak FFI plugin but also allows aliens to be passed as arguments, at least to the extent of passing Alien Callbacks. This means its possible to discard the Alien callout support and use the FFI instead (but just to reiterate to keep the Alien data representation and callback facilities). The project for the next few weekends has to be harmonising the primitive set and functionality of Cog and the standard interpreter now that the StackToRegisterMappingCogit looks complete. FFI has generally worked for me. I am doing a horrible job of handling double arrays, but I am at least able to use them. My "solution" makes assumptions about byte order and I have declare double* as void*. There was mention of extending FFI with callbacks. Given that capability, the only thing missing would then to be make calls on OS threads to avoid blocking the image (but blocking the calling Smalltalk Process for the duration of the call). I have this in prototype and want to release soon. But there is too much else going on right now. Patience please. best Eliot Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] On Behalf Of Torsten Bergmann [astares(a)gmx.de<mailto:astares@gmx.de>] Sent: Tuesday, February 08, 2011 4:04 AM To: pharo-project(a)lists.gforge.inria.fr<mailto:pharo-project@lists.gforge.inria.fr> Subject: [Pharo-project] Status of Alien What is the status of Alien. According to http://bugs.squeak.org/view.php?id=7475 there is no one who confirmed it working on Linux. Any news here? Any ideas on FFI/Alien successor? Thanks T. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

Feb. 9, 2011

Re: [Pharo-project] new Cog VMs available

by Henrik Sperre Johansen

On 09.02.2011 02:31, Schwab,Wilhelm K wrote: > New vms that read cog images - as in cog is no longer a one-way street? That would make it safer/easier to test. Yes. Cheers, Henry

Feb. 9, 2011

Re: [Pharo-project] new Cog VMs available

by Schwab,Wilhelm K

New vms that read cog images - as in cog is no longer a one-way street? That would make it safer/easier to test. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi [leves(a)elte.hu] Sent: Tuesday, February 08, 2011 2:19 PM To: Pharo Development Cc: Squeak Virtual Machine Development Discussion; The general-purpose Squeak developers list Subject: Re: [Pharo-project] new Cog VMs available On Sun, 6 Feb 2011, Eliot Miranda wrote: > Hi All, > > new Cog VMs are available, SimpleStackBasedCogit @ > http://www.mirandabanda.org/files/Cog/VM/VM.r2359/ and > StackToRegisterMappingCogit @ > http://www.mirandabanda.org/files/Cog/VM/VM.r2361. I think the new code > generator is ready for prime time now. I fixed a number of bugs over the > past three weeks and we're now using the StackToRegisterMappingCogit > internally at Teleplace. There's still work to be done merging plugins and > details with the standard VMs but I hope that r2361 is production-ready as > far as core Smalltalk execution is concerned. > > Enjoy. Thanks, StackToRegisterMappingCogit is really impressive. IIRC for the 4.1.1 VM Andreas fixed something about ImageSegment loading which is missing from the CogVMs. It would be good to have that fix, because now arrayOfRoots is nil when I'm trying to load an ImageSegment. It's not urgent at all, because I could work the problem around using the new SqueakVMs which can read Cog images and have the fix. Levente > > > Eliot >

Feb. 9, 2011

Re: [Pharo-project] [COTDC] 5 - PseudoFileStream

by csrabak＠bol.com.br

"If you can't comment and can't find references to it in {core,dev}? image, then remove it!" Em 08/02/2011 19:11, laurent laffont < laurent.laffont(a)gmail.com > escreveu: Time to add COTDC rule #2: If you can't comment it, remove it. Indeed it's compatible with the goal: each day, one less not commented class ! Laurent On Tue, Feb 8, 2011 at 10:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: PseudoFileStream ... may be we could remove it :) Stef On Feb 8, 2011, at 5:39 PM, laurent laffont wrote: > Today: PseudoFileStream > > Comment Of The Day Contest - One Day One Comment > Rules: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent >

Feb. 8, 2011

Re: [Pharo-project] [COTDC] 5 - PseudoFileStream

by StÃ©phane Ducasse

On Feb 8, 2011, at 10:26 PM, Nicolas Cellier wrote: > I try to act as two different things: > - a file entry in a ServerDirectory > - a stream on the content of a file entry > > I am a good example of inheritance pushed to absurd where composition > would be more powerfull and more simple to explain. > Any good soul willing to refactor me is welcome. (Warning, you'll have > to revisit the whole ServerDirectory and its subclasses). :) I love this kind of comments because this is better than no comment and like that we just tell the truth :) > > Good luck > > Nicolas > > 2011/2/8 laurent laffont <laurent.laffont(a)gmail.com>: >> Time to add >> COTDC rule #2: If you can't comment it, remove it. >> Indeed it's compatible with the goal: each day, one less not commented class >> ! >> Laurent >> >> On Tue, Feb 8, 2011 at 10:01 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> PseudoFileStream ... >>> may be we could remove it :) >>> >>> Stef >>> >>> >>> On Feb 8, 2011, at 5:39 PM, laurent laffont wrote: >>> >>>> Today: PseudoFileStream >>>> >>>> Comment Of The Day Contest - One Day One Comment >>>> Rules: Each day a not commented class is elected. Each day the best >>>> comment will be integrated with name of the author(s). >>>> Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >>>> >>>> Laurent >>>> >>> >>> >> >> >

Feb. 8, 2011

Re: [Pharo-project] [COTDC] 5 - PseudoFileStream

by Nicolas Cellier

I try to act as two different things: - a file entry in a ServerDirectory - a stream on the content of a file entry I am a good example of inheritance pushed to absurd where composition would be more powerfull and more simple to explain. Any good soul willing to refactor me is welcome. (Warning, you'll have to revisit the whole ServerDirectory and its subclasses). Good luck Nicolas 2011/2/8 laurent laffont <laurent.laffont(a)gmail.com>: > Time to add > COTDC rule #2: If you can't comment it, remove it. > Indeed it's compatible with the goal: each day, one less not commented class > ! > Laurent > > On Tue, Feb 8, 2011 at 10:01 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> PseudoFileStream ... >> Â Â Â Â may be we could remove it :) >> >> Stef >> >> >> On Feb 8, 2011, at 5:39 PM, laurent laffont wrote: >> >> > Today: PseudoFileStream >> > >> > Comment Of The Day Contest - One Day One Comment >> > Rules: Each day a not commented class is elected. Each day the best >> > comment will be integrated with name of the author(s). >> > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest >> > >> > Laurent >> > >> >> > >

Feb. 8, 2011