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

Re: [Pharo-project] Complex number support discussion

by Schwab,Wilhelm K

Interesting! -----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: Saturday, August 15, 2009 3:50 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion 2009/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > I don't know in what context you mean "scalars," but complex numbers are indeed used as the scalar field for vector spaces. Â That is done both in (abstract) algegra and functional analysis - see Hilbert Space. Â That said, I see what you mean and generally agree. Â Definitely agreed about the linear dimension; complex does not fit in the magnitude hierarchy. Yes, the scalar term is a bit ambiguous, so i'd better stop using it. The wiki gives a disambiguation (http://en.wikipedia.org/wiki/Scalar) and , by scalar i mean Scalar (computing), which defined as: In computing, a scalar is a variable or field that can hold only one value at a time; as opposed to composite variables like array, list, record, etc. In some contexts, a scalar value may be understood to be numeric. A scalar data type is the type of a scalar variable. For example, char, int, float, and double are the most common scalar data types in the C programming language. The origin of the term "scalar" in computing dates back to the 1970s, where the intended meaning was "opposite of vector", so as to distinguish from the idea of vector processing in computer processor design. > > We also have to remember that there are pgragmatic aspects to this. Â We have been over this several times now, so I think we should table this until Ken has time to write up his proposal. > > 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: Saturday, August 15, 2009 3:18 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Complex number support discussion > > Btw, here is another argument why Complex is not part of Number class hierarchy. > > Here what reads the Magnitude class: > > I'm the abstract class Magnitude that provides common protocol for objects that have the ability to be compared along a ___linear dimension___, such as dates or times. > Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as Character and LookupKey. > > --- > > Since complex values is not scalars and hence cannot be compared along a linear dimension, they could not be inherited from a Magnitude. > > Btw this comment seems veeery dated, because it refers to > ArithmeticValue, which not present in current class hierarchy :) > > As you stated earlier that Real set is a subset of Complex, then if you want to see both of them lying in same class hierarchy, it could require a major redesign the class hierarchy to make Complex a base class, and Float/Integer a subclasses. > Since subclasses are specialization of superclasses, and superclass always is more generic than any of its subclass. > > Others could step up and say: hey scalars could be seen as a specialized kind of vectors, and vectors could be seen as a specialized kind of matrices, so lets make Matrix to be the ultimate superclass, and then Vector, and then Scalar etc etc.. > > I can only guess, how far we can go with such generalization(s). > > -- > 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 > -- 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

Aug. 15, 2009

Re: [Pharo-project] ORM for Pharo -- Â½ OFF

by Mariano Martinez Peck

2009/8/15 <csrabak(a)bol.com.br> > Mariano, > > I can understand the goal be Pharo idea and goal as you post. What I'm > trying to bring (and hopefully *add* to this discussion) is how can we > arrive there. > > We need to narrow down the definition of "enterprise application" and see > where Pharo can start to thrive. No all encompassing approach would work as > notwithstanding how poweful and complete Pharo *could *become it will not > be *anytime soon.* > > The notion that Pharo be not assotiated *per se* to any UI it is a strong > (and I vote to maintain it) design goal but in order to push forward Pharo > together with robust and clean implementation we'll need a lot of energy and > effort to produce enough educational materials like tutorial, manuals, etc., > it will be confusing all the time have an example that do not work in > another minor variation of UI (to stay in a single topic). > > So I return to the point: we need to have more clear goals on what > particular realm we see Pharo as feasible for enterprise development and be > able to enumerate what are the advantages of Pharo versus the other > approaches. > I am totally agree. Would like to hear the board opinion. Hope it is more explicit now ;-) > Yes it was ;) > Em 14/08/2009 20:42, *Mariano Martinez Peck < marianopeck(a)gmail.com >*escreveu: > > > > > 2009/8/14 <csrabak(a)bol.com.br<http://mce_host/compose?to=csrabak@bol.com.br> > > > >> >> Mariano, >> >> I agree (and I myself have been on the Research side getting answers >> similar to those ones) in fact I'll add another item to your list: >> >> -- They have an "architectural steering committee" that dictates use of >> some RDBS >> >> I've seen this even requiring some ERP used different database engine thas >> suggested by supplier. . . >> >> So if we want to compete with enterprise applications we need to get into >> some Enterprise: >> >> We're still thinkering with printing in Pharo (and this is PITA when >> attempting to be platform agnostic), so no Report Generator still, no matter >> how well you connect to a RDBS, any slightly above trivial example CRUD >> application will need this support. >> >> Our present set of widgets is sleek but still not as comprehensive as the >> other competing approaches, and we still have not created enough baseline to >> have an "echo system" so third parties can augment them as it happens now >> with Java, .Net and happened (and still as legacy updates) in Delphi and VB. >> >> So if the goal is to reach those enterprise trench we have to find some >> company that would profit of having [Pharo] Smalltalk as a *primary*language to customize or augment their system, as today (say as sake of >> example, SAP has ABAP but with Netweaver is going Java, and they competitors >> similar path). >> >> Let's think about this: historically some (comercial) Smalltalks allowed >> via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things >> similar as VB (in fact even Tcl and Python allow that), but what is the >> "productivity" of programmer that finds a tutorial or an example in VB and >> has to "translate" it to Smalltalk? >> >> As today can we enumerate what would be an advantage of doing something in >> Pharo instead of some "mainstream" language just to do some GUI painting >> CRUD application? >> > I don't know if I understand you. The idea and goal behind Pharo is to have > the open, free, clean and robust smalltalk that we were missing for years > for commercial applications. At least that's my idea of Pharo. It must be a > platform and a base where you can create tools in it and with both of them > create real applications. > > In my opinion Pharo shouldn't be associated with a particular UI (web or > desktop) neither to a persistence strategy. Pharo must be the base of all > that. So then you can have differents alternatives: For UI's you can have > PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But > pharo is not coupled with any of them. You will then choose the solutions > that best feets your needs. > > In summary, I would love to use Pharo as platform to build enterprise and > commercial applications. No matter how do I persist or display my objects. > > Best, > > Mariano > > > >> >> again my 0.01999.... >> >> Regards, >> >> -- >> >> Cesar Rabak >> >> >> >> Em 14/08/2009 16:57, *Mariano Martinez Peck < marianopeck(a)gmail.com<http://mce_host/compose?to=marianopeck@gmail.com>> >> * escreveu: >> >> >> >> >> 2009/8/14 <csrabak(a)bol.com.br<http://mce_host/compose?to=csrabak@bol.com.br> >> > >> >>> Esteban, >>> >>> I'm comenting this on *philosophical* grounds. >>> >>> I understand the efforts to have SqueakDBX and other ORM in Pharo are >>> motivated by Seaside and other "production" initiatives so, again, my food >>> for thought is more an intellectual contribution which I see as useful for >>> Pharo as project: >>> >>> I don't see Pharo *any time soon*Â® having all the toolset to be able to >>> compete in the CRUDÂ¹ realm with more streamlined tools and besides, not >>> matter how much theoretical work has been done on ORM, the "impedance >>> mismatch" is still there, >>> >> Hi! I am agree with you about the "impedance mismatch". I think that if I >> am free to choose a persistence strategy I would use an OODB. However, if we >> are talking about real enterprise application (not a simple webpage) being >> able to choose the persistence strategy is practically impossible. We did a >> survey last year and the results were that most of the times you cannot >> choose. Of course, the client has a lot of reasons: >> >> - The client already has a RDBMS >> - They had paid for it and have the license (sometimes) >> - They want a company's support. The only company here is Gemstone. >> - RDBMS has history and it is an standard >> - They have knowledge about it >> - Interaction with other system (even legazy systems) >> - They are afraid of using another persistence strategy >> - They want to use SQL >> - They have DBAs >> - The persistence is difficult to negotiate >> >> So. In my opinion, if Pharo wants to be used really as a platform for >> enterprise applications (competing to java, .NET, etc), it must have a >> good relational solution. Of course, when you are able to choose, you can go >> for another approach like OODB. >> >> Best, >> >> Mariano >> >>> a recent and practicall account of this (for Squeak) can be found in >>> >>> http://onsmalltalk.com/simple-image-based-persistence-in-squeak >>> >>> also, AIDA/Web has been able to run only storing thing in the image! See >>> >>> >>> http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3b… >>> >>> Since we'll increase the educational efforts to spread Pharo, I think >>> that as technology we should to recover a bit of Smalltalk technology and be >>> first more Object Oriented and then see if ORM still is so needed. >>> >>> my 0.0199999.... >>> >>> -- >>> >>> Cesar Rabak >>> >>> [1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete >>> Em 14/08/2009 16:14, *Esteban A. Maringolo < emaringolo(a)gmail.com<http://mce_host/compose?to=emaringolo@gmail.com>> >>> * escreveu: >>> >>> >>> My prototype is getting less proto, and I found out it doesn't have >>> complex relations, and the system is going to perform faster if I have >>> tables for most of it. >>> >>> What are the choices I have for doing ORM in Pharo? >>> >>> Â¿Does GLORP work? Â¿Any other options? >>> I don't have a strong preference for the RDBMS engine, it can be >>> anything (free), being it MySQL, PostgreSQL or Sql Server Express. >>> >>> Best regards, >>> >>> Esteban A. Maringolo >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr<http://../../../undefined/compose?to=Pharo> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr<http://../../../undefined/compose?to=Pharo> >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr<http://../../../undefined/compose?to=Pharo> >> 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 >

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by csrabak＠bol.com.br

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by Igor Stasenko

2009/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > I don't know in what context you mean "scalars," but complex numbers are indeed used as the scalar field for vector spaces. Â That is done both in (abstract) algegra and functional analysis - see Hilbert Space. Â That said, I see what you mean and generally agree. Â Definitely agreed about the linear dimension; complex does not fit in the magnitude hierarchy. Yes, the scalar term is a bit ambiguous, so i'd better stop using it. The wiki gives a disambiguation (http://en.wikipedia.org/wiki/Scalar) and , by scalar i mean Scalar (computing), which defined as: In computing, a scalar is a variable or field that can hold only one value at a time; as opposed to composite variables like array, list, record, etc. In some contexts, a scalar value may be understood to be numeric. A scalar data type is the type of a scalar variable. For example, char, int, float, and double are the most common scalar data types in the C programming language. The origin of the term "scalar" in computing dates back to the 1970s, where the intended meaning was "opposite of vector", so as to distinguish from the idea of vector processing in computer processor design. > > We also have to remember that there are pgragmatic aspects to this. Â We have been over this several times now, so I think we should table this until Ken has time to write up his proposal. > > 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: Saturday, August 15, 2009 3:18 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Complex number support discussion > > Btw, here is another argument why Complex is not part of Number class hierarchy. > > Here what reads the Magnitude class: > > I'm the abstract class Magnitude that provides common protocol for objects that have the ability to be compared along a ___linear dimension___, such as dates or times. > Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as Character and LookupKey. > > --- > > Since complex values is not scalars and hence cannot be compared along a linear dimension, they could not be inherited from a Magnitude. > > Btw this comment seems veeery dated, because it refers to ArithmeticValue, which not present in current class hierarchy :) > > As you stated earlier that Real set is a subset of Complex, then if you want to see both of them lying in same class hierarchy, it could require a major redesign the class hierarchy to make Complex a base class, and Float/Integer a subclasses. > Since subclasses are specialization of superclasses, and superclass always is more generic than any of its subclass. > > Others could step up and say: hey scalars could be seen as a specialized kind of vectors, and vectors could be seen as a specialized kind of matrices, so lets make Matrix to be the ultimate superclass, and then Vector, and then Scalar etc etc.. > > I can only guess, how far we can go with such generalization(s). > > -- > 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 > -- Best regards, Igor Stasenko AKA sig.

Aug. 15, 2009

Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?

by Schwab,Wilhelm K

THANKS!!! -----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: Saturday, August 15, 2009 3:29 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain? 2009/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? Â It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O. > There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key. See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool at 'Project spawnNewProcessIfThisIsUI: process' > Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. Â I see a few references to such things in Pharo, but I'm fairly lost. Â Where should I start reading and/or browsing? > > 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

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by Schwab,Wilhelm K

Sorry, I do not follow, but I am saying that 3 * 4i makes every bit as much sense as 2/3 * 4.2 and would be implemented by the same mechanism. The programmer's desire to admit comlex and floating point results, respectfully, is clear from the objects that appear in the calculation. However, spuriously injecting complex numbers into what might be real-only computation will as often as not be unhelpful, and a "surprise." Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Saturday, August 15, 2009 3:28 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion So we have to establish when Number>>i will bring an imaginary (hint [for example]: just when Complex is loaded) or something else due programmer discretion? Or your proposal is that double-dispatch only occur if we have Imaginary new: aNumber? Em 15/08/2009 15:26, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: One programmer's expectation is another's broken code, so "surprise" is not a good standard. Perserving long-standing behavior is. Your multiplication example is esaily handled by double-dispatch, and that would not violate "no implicit coercion" because one of the participants is already complex. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of csrabak(a)bol.com.br Sent: Saturday, August 15, 2009 12:18 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion It helps to undestand your suggestion. It does not help to make it Smalltalk friendly, my meaning of that being the "principle of least surprise". If complex math is to be allowed a natural consequence is that a lot of functions would return complex answers for real arguments. How would then have Pharo Smalltalk behave in a case of computing a reactance: X = jÏL? anInductance being Number and complexFrequency obviously being Complex: aReactance := anInductance * complexFrequency Em 15/08/2009 13:55, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: Nothing tricky: just that methods answering complex results should be defined only by things tha are already complex. -1 sqrt blows up; -1 asComplex answers i. There would be no imlicit conversion between real and complex, allowing the base system to perform as it does now and still allowing all the complex number crunching anyone wants to do. Does that help? Bill

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by csrabak＠bol.com.br

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by Igor Stasenko

2009/8/15 <csrabak(a)bol.com.br>: > Igor, > > I think I don't undersand your point. What is the mathematical significance > of an Array of size 0.2i? > the significance is not mathematical, it is practical: how many hours one should spend fixing all 'surprises' which you can introduce if not carefully add Complex support. Let me remind you that Physics is not the only area where is mathematcal apparatus is used. In banking, people using a completely different mathematical apparatus, and i doubt that they using complex values to calculate sums on client's accounts. But i don't have any doubts that such applications require very stable and predictable math functions which operating mainly over real numbers. > Em 15/08/2009 14:35, Igor Stasenko < siguctua(a)gmail.com > escreveu: > > 2009/8/15 : >> It helps to undestand your suggestion. >> >> It does not help to make it Smalltalk friendly, my meaning of that being >> the >> "principle of least surprise". >> > least suprise for who? > For you it could be the least surprise. > For me, and for other people it would be a big surprise. > So, please give a better/different reasoning, why in a presence of > Complex numbers, a functions > which operating with Real numbers should change their behavior. > > Integers are subset of Real set and Real is a subset of Complex, then > one could happily write: > > Array new: 0.2i > > and following your reasoning, the above is good way to write a code > and it should work well. > >> If complex math is to be allowed a natural consequence is that a lot of >> functions would retur n complex answers for real arguments. >> >> How would then have Pharo Smalltalk behave in a case of computing a >> reactance: X = jÏL? >> >> anInductance being Number and complexFrequency obviously being Complex: >> >> aReactance := anInductance * complexFrequency >> >> Em 15/08/2009 13:55, Schwab,Wilhelm K < bschwab(a)anest.ufl.edu > escreveu: >> >> Nothing tricky: just that methods answering complex results should be >> defined only by things tha are already complex.Â -1 sqrt blows up; -1 >> asComplex answers i.Â There would be no imlicit conversion between real >> and >> complex, allowing the base system to perform as it does now and still >> allowing all the complex number crunching anyone wants to do. Does that >> help? >> Bill >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-pr oject(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 > -- Best regards, Igor Stasenko AKA sig.

Aug. 15, 2009

Re: [Pharo-project] Complex number support discussion

by Schwab,Wilhelm K

Sig, I don't know in what context you mean "scalars," but complex numbers are indeed used as the scalar field for vector spaces. That is done both in (abstract) algegra and functional analysis - see Hilbert Space. That said, I see what you mean and generally agree. Definitely agreed about the linear dimension; complex does not fit in the magnitude hierarchy. We also have to remember that there are pgragmatic aspects to this. We have been over this several times now, so I think we should table this until Ken has time to write up his proposal. 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: Saturday, August 15, 2009 3:18 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Complex number support discussion Btw, here is another argument why Complex is not part of Number class hierarchy. Here what reads the Magnitude class: I'm the abstract class Magnitude that provides common protocol for objects that have the ability to be compared along a ___linear dimension___, such as dates or times. Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as Character and LookupKey. --- Since complex values is not scalars and hence cannot be compared along a linear dimension, they could not be inherited from a Magnitude. Btw this comment seems veeery dated, because it refers to ArithmeticValue, which not present in current class hierarchy :) As you stated earlier that Real set is a subset of Complex, then if you want to see both of them lying in same class hierarchy, it could require a major redesign the class hierarchy to make Complex a base class, and Float/Integer a subclasses. Since subclasses are specialization of superclasses, and superclass always is more generic than any of its subclass. Others could step up and say: hey scalars could be seen as a specialized kind of vectors, and vectors could be seen as a specialized kind of matrices, so lets make Matrix to be the ultimate superclass, and then Vector, and then Scalar etc etc.. I can only guess, how far we can go with such generalization(s). -- 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

Aug. 15, 2009

Re: [Pharo-project] Analog to Dolphin's #forkMainIfMain?

by Igor Stasenko

2009/8/15 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Is there anything in Pharo that starts a new main thread to carry on for one that is about to get blocked? Â It might be that Pharo does not need it, since sockets are serviced by the VM, where Dolphin (at least prior to overlapped calls) did the I/O through the event loop; if the main thread stopped, so did Windows event dispatching, and hence no socket I/O. > There is such thing. Try to explore the way how debugger handling this (when process you want to debug is current UI process), or when you pressing interrupt key. See Debugger>>openOn: process context: context label: title contents: contentsStringOrNil fullView: bool at 'Project spawnNewProcessIfThisIsUI: process' > Dolphin to some extent, and WindowBuilder to (IIRC) a large extent create modal loops in Smalltalk code. Â I see a few references to such things in Pharo, but I'm fairly lost. Â Where should I start reading and/or browsing? > > 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.

Aug. 15, 2009