September 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Launching class form command line ...

by Lukas Renggli

> How does Pharo execute classes from the command line? You can pass the filename of a .cs/.st file to the VM that gets filed-in on startup. > Is there a way to specify the class and the method to be called? Not directly. > Are command line arguments available? $ squeak --help Usage: squeak [<option>...] [<imageName> [<argument>...]] squeak [<option>...] -- [<argument>...] FBDev <option>s: -fbdev <dev> use framebuffer device <dev> (default: /dev/fb) -kbmap <file> load keymap from <file> (default: use kernel keymap) -msdev <dev> use mouse device <dev> (default: /dev/psaux) -msproto <protocol> use the given <protocol> for the mouse (default: ps2) -vtlock disallow all vt switching (for any reason) -vtswitch enable keyboard vt switching (Alt+FNx) Common <option>s: -encoding <enc> set the internal character encoding (default: MacRoman) -help print this help message, then exit -memory <size>[mk] use fixed heap size (added to image size) -mmap <size>[mk] limit dynamic heap size (default: 1024m) -noevents disable event-driven input support -notimer disable interval timer for low-res clock -pathenc <enc> set encoding for pathnames (default: UTF-8) -plugins <path> specify alternative plugin location (see manpage) -textenc <enc> set encoding for external text (default: UTF-8) -version print version information, then exit -vm-<sys>-<dev> use the <dev> driver for <sys> (see below) Deprecated: -display <dpy> quivalent to '-vm-display-X11 -display <dpy>' -headless quivalent to '-vm-display-X11 -headless' -nodisplay quivalent to '-vm-display-null' -nosound quivalent to '-vm-sound-null' -quartz quivalent to '-vm-display-Quartz' Notes: <imageName> defaults to `squeak.image'. -vtlock disables keyboard vt switching even when -vtswitch is enabled If `-memory' is not specified then the heap will grow dynamically. <argument>s are ignored, but are processed by the Squeak image. The first <argument> normally names a Squeak `script' to execute. Precede <arguments> by `--' to use default image. Available drivers: vm-sound-null vm-sound-custom vm-display-custom vm-display-null vm-display-fbdev -- Lukas Renggli www.lukas-renggli.ch

Sept. 21, 2010

[Pharo-project] Launching class form command line ...

by James Ladd

Hi All, How does Pharo execute classes from the command line? Is there a way to specify the class and the method to be called? Are command line arguments available? I want to put the same mechanism in Redline Smalltalk. Rgs, James.

Sept. 21, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Jimmie Houchin

Sept. 21, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Schwab,Wilhelm K

the one running the gui ________________________________________ 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: Monday, September 20, 2010 10:14 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. Where? In the Socket class? And what's the "main thread"? Levente > > > > ________________________________________ > 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: Monday, September 20, 2010 8:13 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> Levente, >> >> If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. > > I guess you're using Socket>>#connectTo:port: which uses > Socket class>>#standardTimeout as timeout (45 seconds). If you don't want > the default timeout, use #connectTo:port:waitForConnectionFor: or > implement your own low level method which waits on semaphore until it's > signaled. If you want to terminate the connection attempt, just signal the > semaphore yourself, like here: > > s := Socket newTCP. > s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." > [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." > s semaphore waitTimeoutMSecs: 1000. > s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." > > And for ConnectionQueue, simply don't use it if you don't like it. It > doesn't have to poll at all, AFAIK it's just implemented that way. > Since Sockets use Semaphores which are signaled by the SocketPlugin, they > don't block the image at all. But correct me if I'm wrong. > > > Levente > >> >> Bill >> >> >> >> ________________________________________ >> 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: Monday, September 20, 2010 7:01 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >> >>> Guillermo, >>> >>> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. >> >> When does a Socket block the image? >> >> >> Levente >> >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>> Sent: Sunday, September 19, 2010 10:56 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >>> >>> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >>> >>> Guille >>> >>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>>> >>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>> where you can add any properties to object >>> on the fly, without need of adding a methods or declaring additional >>> instance variable in class... >>> >>>> >>>> >>>> >>>> ________________________________________ >>>> 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 Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>> Sent: Sunday, September 19, 2010 7:56 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>> >>>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>>> hi guys >>>>> >>>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>>> So we should really have a way to specify silent ui action. >>>>> Does anybody have an idea how I could do that? >>>>> >>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>>> >>>> >>>> use morph propertyAt: #borderStyle >>>> so you don't have to break your head with it :) >>>> >>>> BorderedMorph having an enormous number of subclasses, while some of >>>> them even don't using any >>>> kind of borders. That's makes me wonder if anything like color, border >>>> style etc should belong to root classes >>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>> properties (which is currently sits in morphic >>>> extensions are more appropriate storage for them). The only problem is >>>> that accessing them is much slower than ivars. >>>> >>>>> Stef >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >>> >>> >>> _______________________________________________ >>> 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 >

Sept. 21, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Levente Uzonyi

On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. Where? In the Socket class? And what's the "main thread"? Levente > > > > ________________________________________ > 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: Monday, September 20, 2010 8:13 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> Levente, >> >> If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. > > I guess you're using Socket>>#connectTo:port: which uses > Socket class>>#standardTimeout as timeout (45 seconds). If you don't want > the default timeout, use #connectTo:port:waitForConnectionFor: or > implement your own low level method which waits on semaphore until it's > signaled. If you want to terminate the connection attempt, just signal the > semaphore yourself, like here: > > s := Socket newTCP. > s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." > [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." > s semaphore waitTimeoutMSecs: 1000. > s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." > > And for ConnectionQueue, simply don't use it if you don't like it. It > doesn't have to poll at all, AFAIK it's just implemented that way. > Since Sockets use Semaphores which are signaled by the SocketPlugin, they > don't block the image at all. But correct me if I'm wrong. > > > Levente > >> >> Bill >> >> >> >> ________________________________________ >> 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: Monday, September 20, 2010 7:01 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: >> >>> Guillermo, >>> >>> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. >> >> When does a Socket block the image? >> >> >> Levente >> >>> >>> Bill >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >>> Sent: Sunday, September 19, 2010 10:56 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >>> >>> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >>> >>> Guille >>> >>> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >>> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>>> >>> Yeah, it would be much easier to deal that line in Self or JavaScript, >>> where you can add any properties to object >>> on the fly, without need of adding a methods or declaring additional >>> instance variable in class... >>> >>>> >>>> >>>> >>>> ________________________________________ >>>> 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 Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>>> Sent: Sunday, September 19, 2010 7:56 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>>> >>>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>>> hi guys >>>>> >>>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>>> So we should really have a way to specify silent ui action. >>>>> Does anybody have an idea how I could do that? >>>>> >>>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>>> >>>> >>>> use morph propertyAt: #borderStyle >>>> so you don't have to break your head with it :) >>>> >>>> BorderedMorph having an enormous number of subclasses, while some of >>>> them even don't using any >>>> kind of borders. That's makes me wonder if anything like color, border >>>> style etc should belong to root classes >>>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>>> properties (which is currently sits in morphic >>>> extensions are more appropriate storage for them). The only problem is >>>> that accessing them is much slower than ivars. >>>> >>>>> Stef >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >>> >>> >>> _______________________________________________ >>> 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 >

Sept. 21, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Schwab,Wilhelm K

Scratch around, and you will find that the time limits are there to allow calls to made on the main thread. ________________________________________ 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: Monday, September 20, 2010 8:13 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > Levente, > > If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here: s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong. Levente > > Bill > > > > ________________________________________ > 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: Monday, September 20, 2010 7:01 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> Guillermo, >> >> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. > > When does a Socket block the image? > > > Levente > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >> Sent: Sunday, September 19, 2010 10:56 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >> >> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >> >> Guille >> >> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>> >> Yeah, it would be much easier to deal that line in Self or JavaScript, >> where you can add any properties to object >> on the fly, without need of adding a methods or declaring additional >> instance variable in class... >> >>> >>> >>> >>> ________________________________________ >>> 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 Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>> Sent: Sunday, September 19, 2010 7:56 PM >>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>> hi guys >>>> >>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>> So we should really have a way to specify silent ui action. >>>> Does anybody have an idea how I could do that? >>>> >>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>> >>> >>> use morph propertyAt: #borderStyle >>> so you don't have to break your head with it :) >>> >>> BorderedMorph having an enormous number of subclasses, while some of >>> them even don't using any >>> kind of borders. That's makes me wonder if anything like color, border >>> style etc should belong to root classes >>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>> properties (which is currently sits in morphic >>> extensions are more appropriate storage for them). The only problem is >>> that accessing them is much slower than ivars. >>> >>>> Stef >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >>> >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 >

Sept. 21, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Igor Stasenko

On 21 September 2010 02:45, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > There are no doubt a growing list of reasons, but the big one is usability. Â Squeak's (lack of) concept of input focus is a HUGE pain; its defaults of mouse buttons are weird. Â I could go on, but I prefer to use and (to the extent that I can) help to advance Pharo. > I like to use both. And i paying attention to make my projects to run on both projects w/o problems. Both currently are constantly improving in UI and code quality areas. Both having own pros and cons, but its natural, since they are separate projects. > > > ________________________________________ > 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: Monday, September 20, 2010 6:44 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [squeak-dev] Morphic > > On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> Jumping in here, I used Squeak just a month or two ago to look at its serial port code, and something else IIRC. Â I much prefer Pharo. > > And why? > > > Levente > >> >> >> >> ________________________________________ >> 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: Monday, September 20, 2010 5:30 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] [squeak-dev] Morphic >> >> On Mon, 20 Sep 2010, Hilaire Fernandes wrote: >> >>> Le 20/09/2010 17:50, Levente Uzonyi a Ã©crit : >>>> On Sat, 18 Sep 2010, Hilaire Fernandes wrote: >>>> >>>>> Really I don't understand CUIS long term objective, why this work is not >>>>> done in Pharo? They share the same vision. >>>> >>>> You could ask the same question with Pharo and Squeak instead of Cuis >>>> and Pharo, couldn't you? >>> >>> No, I can't. >>> >>> Pharo provides me a clear vision I can thrust: a Smalltalk environment >>> to build third party applications (ie makes my developer life easier). >>> Squeak does not provide me this thrust nor indication of that direction. >> >> When was the last time you used Squeak? >> >>> You can object it is matter of point of view, I will object it is a >>> matter of ressources you can allocate to write an application. Mine Â are >>> limited: I start writing DrGeo under Squeak, then I continued with >>> Pharo. I can really fell the difference: nice Widgets, cleaner system I >>> can understand, ease to integrate changes/improvements upstream. All in >>> all, I get the job done more nicely from my perspective. >> >> So you're using Pharo because of Polymorph? >> >>> >>> In the past, project got hudge resources (ie Sophie), this project >>> failed to give back to the community in a proper way. Was it because >> >> I don't really get this, which project are you talking about? >> >> >> Levente >> >>> Squeak defunct development model? I think so. IMHO, Pharo is trying to >>> fix that, and this is terribly important for a community. >>> >>> Now, Squeak model of development is may be different, so it may not >>> happen again, I don't know. >>> >>>> IMHO the reason is having total control and that's the same reason why >>>> Pharo was created. >>> >>> This does not matter. >>> >>> Hilaire >>> >>> -- >>> Dr. Geo, to discover geometry on Linux, Windows, MAC and XO >>> http://community.ofset.org/index.php/DrGeo >>> >>> >>> _______________________________________________ >>> 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 > -- Best regards, Igor Stasenko AKA sig.

Sept. 21, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Levente Uzonyi

On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > Levente, > > If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. I guess you're using Socket>>#connectTo:port: which uses Socket class>>#standardTimeout as timeout (45 seconds). If you don't want the default timeout, use #connectTo:port:waitForConnectionFor: or implement your own low level method which waits on semaphore until it's signaled. If you want to terminate the connection attempt, just signal the semaphore yourself, like here: s := Socket newTCP. s connectNonBlockingTo: #[127 0 0 1] port: 19327. "Random port which is not open." [ 500 milliSeconds asDelay wait. s semaphore signal ] fork. "This process will stop the connection attempt." s semaphore waitTimeoutMSecs: 1000. s statusString. "This will simply print the socket status. You can terminate the process here if the socket is connected, etc." And for ConnectionQueue, simply don't use it if you don't like it. It doesn't have to poll at all, AFAIK it's just implemented that way. Since Sockets use Semaphores which are signaled by the SocketPlugin, they don't block the image at all. But correct me if I'm wrong. Levente > > Bill > > > > ________________________________________ > 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: Monday, September 20, 2010 7:01 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > >> Guillermo, >> >> One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. > > When does a Socket block the image? > > > Levente > >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] >> Sent: Sunday, September 19, 2010 10:56 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. >> >> And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. >> >> Guille >> >> On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: >> On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >>> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >>> >> Yeah, it would be much easier to deal that line in Self or JavaScript, >> where you can add any properties to object >> on the fly, without need of adding a methods or declaring additional >> instance variable in class... >> >>> >>> >>> >>> ________________________________________ >>> 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 Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >>> Sent: Sunday, September 19, 2010 7:56 PM >>> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >>> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >>> >>> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>>> hi guys >>>> >>>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>>> So we should really have a way to specify silent ui action. >>>> Does anybody have an idea how I could do that? >>>> >>>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>>> >>> >>> use morph propertyAt: #borderStyle >>> so you don't have to break your head with it :) >>> >>> BorderedMorph having an enormous number of subclasses, while some of >>> them even don't using any >>> kind of borders. That's makes me wonder if anything like color, border >>> style etc should belong to root classes >>> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >>> properties (which is currently sits in morphic >>> extensions are more appropriate storage for them). The only problem is >>> that accessing them is much slower than ivars. >>> >>>> Stef >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >>> >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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 >

Sept. 21, 2010

Re: [Pharo-project] we need to find a way to declare that an action is UIless

by Schwab,Wilhelm K

Levente, If they worked correctly, they would, at least under naive client conditions - a connection attempt should try until it is told (#terminate) to stop. Severs that listen for a limited time are broken by design. ConnectionQueue polls as a result - it's pretty bad. Bill ________________________________________ 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: Monday, September 20, 2010 7:01 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > Guillermo, > > One has to be careful with assuming that something affects only part of the image. Much of Squeak's networking trouble comes from the fact that it was designed to block the image for a limited time when it should have been blocking only one Process *indefinitely*. But, the remedy for working while blocking operations happen in the background is threading, and most of the image is deliberately not thread safe. When does a Socket block the image? Levente > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Guillermo Polito [guillermopolito(a)gmail.com] > Sent: Sunday, September 19, 2010 10:56 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless > > +1 to Bill's. If we can't have a feedback from the system while doing silent actions, we can think it just freezed :S. > > And it's something already dicussed, but I don't like actions that affect only a part of the system blocking my whole image. > > Guille > > On Sun, Sep 19, 2010 at 10:40 PM, Igor Stasenko <siguctua(a)gmail.com<mailto:siguctua@gmail.com>> wrote: > On 20 September 2010 03:09, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: >> Slow access can be a big problem. Any such change should be made based on measurements so we know what benefit we get at what cost. >> > Yeah, it would be much easier to deal that line in Self or JavaScript, > where you can add any properties to object > on the fly, without need of adding a methods or declaring additional > instance variable in class... > >> >> >> >> ________________________________________ >> 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 Igor Stasenko [siguctua(a)gmail.com<mailto:siguctua@gmail.com>] >> Sent: Sunday, September 19, 2010 7:56 PM >> To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> >> Subject: Re: [Pharo-project] we need to find a way to declare that an action is UIless >> >> On 19 September 2010 13:12, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: >>> hi guys >>> >>> I tried to add borderStyle to BorderedMorph and the progressbar showing the progress blow up. >>> So we should really have a way to specify silent ui action. >>> Does anybody have an idea how I could do that? >>> >>> [BorderedMorph addInstVarNamed: 'borderStyle'] silent would be cool. >>> >> >> use morph propertyAt: #borderStyle >> so you don't have to break your head with it :) >> >> BorderedMorph having an enormous number of subclasses, while some of >> them even don't using any >> kind of borders. That's makes me wonder if anything like color, border >> style etc should belong to root classes >> in hierarchy, like Morph or BorderedMorph. I think that dynamic set of >> properties (which is currently sits in morphic >> extensions are more appropriate storage for them). The only problem is >> that accessing them is much slower than ivars. >> >>> Stef >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 >> >> _______________________________________________ >> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2010

Re: [Pharo-project] [squeak-dev] Morphic

by Schwab,Wilhelm K

There are no doubt a growing list of reasons, but the big one is usability. Squeak's (lack of) concept of input focus is a HUGE pain; its defaults of mouse buttons are weird. I could go on, but I prefer to use and (to the extent that I can) help to advance Pharo. ________________________________________ 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: Monday, September 20, 2010 6:44 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] Morphic On Mon, 20 Sep 2010, Schwab,Wilhelm K wrote: > Jumping in here, I used Squeak just a month or two ago to look at its serial port code, and something else IIRC. I much prefer Pharo. And why? Levente > > > > ________________________________________ > 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: Monday, September 20, 2010 5:30 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [squeak-dev] Morphic > > On Mon, 20 Sep 2010, Hilaire Fernandes wrote: > >> Le 20/09/2010 17:50, Levente Uzonyi a Ã©crit : >>> On Sat, 18 Sep 2010, Hilaire Fernandes wrote: >>> >>>> Really I don't understand CUIS long term objective, why this work is not >>>> done in Pharo? They share the same vision. >>> >>> You could ask the same question with Pharo and Squeak instead of Cuis >>> and Pharo, couldn't you? >> >> No, I can't. >> >> Pharo provides me a clear vision I can thrust: a Smalltalk environment >> to build third party applications (ie makes my developer life easier). >> Squeak does not provide me this thrust nor indication of that direction. > > When was the last time you used Squeak? > >> You can object it is matter of point of view, I will object it is a >> matter of ressources you can allocate to write an application. Mine are >> limited: I start writing DrGeo under Squeak, then I continued with >> Pharo. I can really fell the difference: nice Widgets, cleaner system I >> can understand, ease to integrate changes/improvements upstream. All in >> all, I get the job done more nicely from my perspective. > > So you're using Pharo because of Polymorph? > >> >> In the past, project got hudge resources (ie Sophie), this project >> failed to give back to the community in a proper way. Was it because > > I don't really get this, which project are you talking about? > > > Levente > >> Squeak defunct development model? I think so. IMHO, Pharo is trying to >> fix that, and this is terribly important for a community. >> >> Now, Squeak model of development is may be different, so it may not >> happen again, I don't know. >> >>> IMHO the reason is having total control and that's the same reason why >>> Pharo was created. >> >> This does not matter. >> >> Hilaire >> >> -- >> Dr. Geo, to discover geometry on Linux, Windows, MAC and XO >> http://community.ofset.org/index.php/DrGeo >> >> >> _______________________________________________ >> 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 >

Sept. 20, 2010