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

[Pharo-project] Issue 3101: Wrong Monticello packages initialization order

by Pavel Krivanek

see http://code.google.com/p/pharo/issues/detail?id=3101 Cheers, -- Pavel

Oct. 14, 2010

Re: [Pharo-project] [SPAM] [squeak-dev] Xtreams tests green

by Sven Van Caekenberghe

On 13 Oct 2010, at 21:29, Nicolas Cellier wrote: > So I updated Squeak Xtreams to synchronize with Martin's latest > changes in public store... > Tests are now green, and there is no lingering process :) Super! > If you update, you might have to reinitialize XTEncoder and its > subclasses (may be force Encoders := nil manually) - I don't trust MC > too much with this regard... > The manual step might be necessary because I switched to Symbol rather > than String for specifyinh an encoding. > > I did not deviate from VW version, apart: > - changing the #timeout:server:client: comment > - changing FileWriteStream comment: > isPositionable <Boolean> false when the file is open in append mode > > todo: SocketRead/WriteStream would be nice, +1 > streaming on directory > contents too - I did not do it, because a simple test like > #isDirectory is all but obvious using FileDirectory :( ;-) > The InterpretedStream (for reading writing binary data) shouldn't be that hard. > I'm making a pause tonight. You earned it. > Nicolas Sven

Oct. 14, 2010

[Pharo-project] BUG report

by HwaJong Oh

I have experienced Autotest-LaurentLaffont.62.mcz does not display any test results, while Autotest-jl.61.mcz does. -- View this message in context: http://forum.world.st/Autotest-TDD-screencast-tp2243786p2994899.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 14, 2010

Re: [Pharo-project] Issue 3090: Context not included in ImageSegment when saving morph to file

by Sheridan Mahoney

Oct. 14, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.1.1 OneClickCogVm

by GermÃ¡n Arduino

Forgot this mail, now found the other thread talking about this.....Sorry. 2010/10/13 GermÃ¡n Arduino <garduino(a)gmail.com>: > This is what is happening here with Ubuntu 10.04, but I've libuuid1 installed. > > What I should do to use Cog ? > > Thanks. > > > 2010/9/30 Levente Uzonyi <leves(a)elte.hu>: >> On Thu, 30 Sep 2010, laurent laffont wrote: >> >>> On up to date ArchLinux, 32 bits. >>> >>> 1. Open One Click >>> 2. Open MonticelloBrowser >>> 3. Save a packages (Tests for ex.) in package cache >>> 4. Dialog to enter commit message opens, click ok >>> 5. crash >>> >>> It reminds me about the UUID plugin as external problem. It should be >>> built >>> as internal. >> >> No, it shouldn't. It immediately crashes, if libuuid is not available, which >> happens to be the case on some 64-bit version of Debian and Ubuntu. >> >> >> Levente >> > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

Oct. 13, 2010

Re: [Pharo-project] [Pharo-users] [ANN] Pharo 1.1.1 OneClickCogVm

by GermÃ¡n Arduino

This is what is happening here with Ubuntu 10.04, but I've libuuid1 installed. What I should do to use Cog ? Thanks. 2010/9/30 Levente Uzonyi <leves(a)elte.hu>: > On Thu, 30 Sep 2010, laurent laffont wrote: > >> On up to date ArchLinux, 32 bits. >> >> 1. Open One Click >> 2. Open MonticelloBrowser >> 3. Save a packages (Tests for ex.) in package cache >> 4. Dialog to enter commit message opens, click ok >> 5. crash >> >> It reminds me about the UUID plugin as external problem. It should be >> built >> as internal. > > No, it shouldn't. It immediately crashes, if libuuid is not available, which > happens to be the case on some 64-bit version of Debian and Ubuntu. > > > Levente >

Oct. 13, 2010

Re: [Pharo-project] Xtreams vs become:

by Nicolas Cellier

2010/10/13 <mkobetic(a)gmail.com>: > Michael and I talked about this today a bit and here's what we're thinking about doing. > We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one in CollectionWriteStream>>close. If we're not eliminating the become: from growing then ripping it out of closing creates a strange inconsistency. > > At the same time nothing is preventing the Squeak port to do away with the become:s altogether. After all the terminals are meant to be dialect specific and so the two ports will just be different in this regard. It's probably worth highlighting in the comments/docs that assuming the "become:" semantics of growing makes one's code non-portable. This way one can both get the the traditional behavior in VW, but at the same time Squeak doesn't have to suffer unnecessarily. > > To remove the "become" assumption in the test suite, I'll rewrite all the ReadWriteTests splitting them up into writing and reading part, which will allow creating the input after writing into the output is already done. That way we don't care if the collection streams use become or not. Something like: > > testBlah > > Â Â Â Â self write: [ :output | .... ] > Â Â Â Â Â Â Â Â read: [ :input | ... ] > > Good enough ? > Seems fair to me. Nicolas > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 13, 2010

[Pharo-project] Xtreams vs become:

by mkobetic＠gmail.com

Michael and I talked about this today a bit and here's what we're thinking about doing. We're inheriting the become: behavior from the collection growing APIs in VW and it doesn't make sense to work around that there. Consequently the only (relevant) become: that we do in Xtreams code is the one in CollectionWriteStream>>close. If we're not eliminating the become: from growing then ripping it out of closing creates a strange inconsistency. At the same time nothing is preventing the Squeak port to do away with the become:s altogether. After all the terminals are meant to be dialect specific and so the two ports will just be different in this regard. It's probably worth highlighting in the comments/docs that assuming the "become:" semantics of growing makes one's code non-portable. This way one can both get the the traditional behavior in VW, but at the same time Squeak doesn't have to suffer unnecessarily. To remove the "become" assumption in the test suite, I'll rewrite all the ReadWriteTests splitting them up into writing and reading part, which will allow creating the input after writing into the output is already done. That way we don't care if the collection streams use become or not. Something like: testBlah self write: [ :output | .... ] read: [ :input | ... ] Good enough ?

Oct. 13, 2010

[Pharo-project] Xtreams tests green

by Nicolas Cellier

So I updated Squeak Xtreams to synchronize with Martin's latest changes in public store... Tests are now green, and there is no lingering process :) If you update, you might have to reinitialize XTEncoder and its subclasses (may be force Encoders := nil manually) - I don't trust MC too much with this regard... The manual step might be necessary because I switched to Symbol rather than String for specifyinh an encoding. I did not deviate from VW version, apart: - changing the #timeout:server:client: comment - changing FileWriteStream comment: isPositionable <Boolean> false when the file is open in append mode todo: SocketRead/WriteStream would be nice, streaming on directory contents too - I did not do it, because a simple test like #isDirectory is all but obvious using FileDirectory :( The InterpretedStream (for reading writing binary data) shouldn't be that hard. I'm making a pause tonight. Nicolas

Oct. 13, 2010

Re: [Pharo-project] [squeak-dev] Re: How about atomic value-swap bytecode?

by Igor Stasenko

2010/10/13 Levente Uzonyi <leves(a)elte.hu>: > On Tue, 12 Oct 2010, Igor Stasenko wrote: > >> On 12 October 2010 16:51, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >>> On Tue, 12 Oct 2010, Igor Stasenko wrote: >>> >>>> Hello, i just thought, that it would be cool to have a special bytecode, >>>> which guarantees atomicity for swapping values between two variables. >>>> >>>> To swap two values, you usually do: >>>> >>>> | var1 var2 temp | >>>> >>>> temp := var1. >>>> var1 := var2. >>>> var2 := temp. >>>> >>>> But since its non-atomic, a process can be interrupted and such >>>> operation >>>> is not thread-safe. >>>> >>>> In order to make it thread safe, you must add even more boilerplate: >>>> >>>> | var1 var2 temp | >>>> >>>> semaphore critical: [ >>>> Â temp := var1. >>>> Â var1 := var2. >>>> Â var2 := temp. >>>> ] >>> >>> An alternative solution: >>> >>> | a b | >>> a := 1. >>> b := 2. >>> [ >>> Â Â Â Â | tmp | >>> Â Â Â Â tmp := a. >>> Â Â Â Â a := b. >>> Â Â Â Â b := tmp ] valueUnpreemptively >>> >> >> Yeah, another boilerplate under the hood, also highly dependent from >> scheduling nuances :) > > I don't get the "dependency from scheduling nuances part", but here's my > idea: i don't like the code, which assuming that scheduling works in some specific way, or some code can't be interrupted in the middle. See Semaphore>>critical: for excersise. | caught | caught := false. ^[ caught := true. self wait. mutuallyExcludedBlock value ] ensure: [ caught ifTrue: [self signal] ] this code assuming that between caught := true. and self wait. no interrupt possible. But if it is, then the above implementation is incorrect. > > Add the compiler changes to support :=: as atomic swap. We don't really need > a bytecode for now, since a sequence of assignments is currently atomic. So > the compiler could compile :=: as three assignments using a hidden temporary > variable. On other systems, :=: can be compiled differently. > For same reason, there is no any guarantees from VM side that three assignments in a row will be atomic: storing pointer could trigger a root check, and if roots table is full, it could trigger GC, and after GC, there is a finalization semaphore, which could switch an active process immediately. VM is evolving and subject to change. Having a clear rule which guarantees a specific behavior is far more beneficial comparing to intimate knowledge about how VM works (now). > > Levente > >> >> valueUnpreemptively >> Â Â Â Â "Evaluate the receiver (block), without the possibility of >> preemption >> by higher priority processes. Use this facility VERY sparingly!" >> Â Â Â Â "Think about using Block>>valueUninterruptably first, and think >> about >> using Semaphore>>critical: before that, and think about redesigning >> your application even before that! >> Â Â Â Â After you've done all that thinking, go right ahead and use it..." >> Â Â Â Â | activeProcess oldPriority result | >> Â Â Â Â activeProcess := Processor activeProcess. >> Â Â Â Â oldPriority := activeProcess priority. >> Â Â Â Â activeProcess priority: Processor highestPriority. >> Â Â Â Â result := self ensure: [activeProcess priority: oldPriority]. >> Â Â Â Â "Yield after restoring priority to give the preempted processes a >> chance to run" >> Â Â Â Â Processor yield. >> Â Â Â Â ^result >>> >>> Levente >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- Best regards, Igor Stasenko AKA sig.

Oct. 13, 2010

[Pharo-project] Iliad 0.9.1 released

by Nicolas Petton

Hi, We are happy to announce the release of Iliad 0.9.1 for GNU Smalltalk, Pharo and Squeak. This is a bug fix release. Download & installation instructions can be found at http://www.iliadproject.org/pages/Download. The website also received some love and is now wearing a new design. Happy Iliad hacking, Nicolas Petton & SÃ©bastien Audier

Oct. 13, 2010

Re: [Pharo-project] [squeak-dev] OCompletion usability

by Chris Muller

+1. cmd+j is essential. As are the other unconventional editor features;; cmd+h, g, and e... On Sun, Oct 10, 2010 at 7:06 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi all, > Thanks to Levente, I activated OCompletion in trunk. > It's nice when typing a text from scratch (like in a workspace). > But when modifying an existing text, not that great. > > The feature I most miss is the ability to overwrite a word fragment > and hit cmd+j to repeat the replacement. > Would it be possible to restore this behavior ? > > Nicolas > >

Oct. 13, 2010

Re: [Pharo-project] [squeak-dev] Re: How about atomic value-swap bytecode?

by Schwab,Wilhelm K

FWIW, Dolphin has (or at least had in earlier versions - I can check later if it matters) an analog to #valueUnpreemptively. Something like that is likely to be more portable than new syntax or a new bytecode. Any VW experts care to comment on what might be available there? 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: Wednesday, October 13, 2010 1:00 PM To: The general-purpose Squeak developers list Cc: Pharo Development Subject: Re: [Pharo-project] [squeak-dev] Re: How about atomic value-swap bytecode? On Tue, 12 Oct 2010, Igor Stasenko wrote: > On 12 October 2010 16:51, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Tue, 12 Oct 2010, Igor Stasenko wrote: >> >>> Hello, i just thought, that it would be cool to have a special bytecode, >>> which guarantees atomicity for swapping values between two variables. >>> >>> To swap two values, you usually do: >>> >>> | var1 var2 temp | >>> >>> temp := var1. >>> var1 := var2. >>> var2 := temp. >>> >>> But since its non-atomic, a process can be interrupted and such operation >>> is not thread-safe. >>> >>> In order to make it thread safe, you must add even more boilerplate: >>> >>> | var1 var2 temp | >>> >>> semaphore critical: [ >>> temp := var1. >>> var1 := var2. >>> var2 := temp. >>> ] >> >> An alternative solution: >> >> | a b | >> a := 1. >> b := 2. >> [ >> | tmp | >> tmp := a. >> a := b. >> b := tmp ] valueUnpreemptively >> > > Yeah, another boilerplate under the hood, also highly dependent from > scheduling nuances :) I don't get the "dependency from scheduling nuances part", but here's my idea: Add the compiler changes to support :=: as atomic swap. We don't really need a bytecode for now, since a sequence of assignments is currently atomic. So the compiler could compile :=: as three assignments using a hidden temporary variable. On other systems, :=: can be compiled differently. Levente > > valueUnpreemptively > "Evaluate the receiver (block), without the possibility of preemption > by higher priority processes. Use this facility VERY sparingly!" > "Think about using Block>>valueUninterruptably first, and think about > using Semaphore>>critical: before that, and think about redesigning > your application even before that! > After you've done all that thinking, go right ahead and use it..." > | activeProcess oldPriority result | > activeProcess := Processor activeProcess. > oldPriority := activeProcess priority. > activeProcess priority: Processor highestPriority. > result := self ensure: [activeProcess priority: oldPriority]. > "Yield after restoring priority to give the preempted processes a > chance to run" > Processor yield. > ^result >> >> Levente >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Oct. 13, 2010

Re: [Pharo-project] [squeak-dev] Re: How about atomic value-swap bytecode?

by Levente Uzonyi

On Tue, 12 Oct 2010, Igor Stasenko wrote: > On 12 October 2010 16:51, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Tue, 12 Oct 2010, Igor Stasenko wrote: >> >>> Hello, i just thought, that it would be cool to have a special bytecode, >>> which guarantees atomicity for swapping values between two variables. >>> >>> To swap two values, you usually do: >>> >>> | var1 var2 temp | >>> >>> temp := var1. >>> var1 := var2. >>> var2 := temp. >>> >>> But since its non-atomic, a process can be interrupted and such operation >>> is not thread-safe. >>> >>> In order to make it thread safe, you must add even more boilerplate: >>> >>> | var1 var2 temp | >>> >>> semaphore critical: [ >>> Â temp := var1. >>> Â var1 := var2. >>> Â var2 := temp. >>> ] >> >> An alternative solution: >> >> | a b | >> a := 1. >> b := 2. >> [ >> Â Â Â Â | tmp | >> Â Â Â Â tmp := a. >> Â Â Â Â a := b. >> Â Â Â Â b := tmp ] valueUnpreemptively >> > > Yeah, another boilerplate under the hood, also highly dependent from > scheduling nuances :) I don't get the "dependency from scheduling nuances part", but here's my idea: Add the compiler changes to support :=: as atomic swap. We don't really need a bytecode for now, since a sequence of assignments is currently atomic. So the compiler could compile :=: as three assignments using a hidden temporary variable. On other systems, :=: can be compiled differently. Levente > > valueUnpreemptively > "Evaluate the receiver (block), without the possibility of preemption > by higher priority processes. Use this facility VERY sparingly!" > "Think about using Block>>valueUninterruptably first, and think about > using Semaphore>>critical: before that, and think about redesigning > your application even before that! > After you've done all that thinking, go right ahead and use it..." > | activeProcess oldPriority result | > activeProcess := Processor activeProcess. > oldPriority := activeProcess priority. > activeProcess priority: Processor highestPriority. > result := self ensure: [activeProcess priority: oldPriority]. > "Yield after restoring priority to give the preempted processes a > chance to run" > Processor yield. > ^result >> >> Levente >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Oct. 13, 2010

[Pharo-project] FreeType fonts scan annoyance on windows

by Igor Stasenko

If you're on Windows, a freetype searching fonts everywhere on all drive letters. This causes opening annoying 'Insert disk in drive X:' dialog. guessWindowsFontFolderPath "Guess the location of the Windows font folder" | possibles | possibles := Set new. 'cdefghijklmnopqrstuvwxyz' do:[:drive | #('\windows\fonts' '\winnt\fonts') do:[:path | | d | (d := FileDirectory on: drive asString, ':', path) exists ifTrue:[possibles add: d]]]. possibles := possibles asSortedCollection: [:a :b | a directoryEntry creationTime >= b directoryEntry creationTime]. possibles ifNotEmpty:[^possibles first pathName]. ^nil Here what i found occasionally, when read ReadFile() function documentation in MSDN: If you are attempting to read from a floppy drive that does not have a floppy disk, the system displays a message box that prompts the user to retry the operation. To prevent the system from displaying this message box, call the SetErrorMode function with SEM_NOOPENFILEERRORBOX. But it will require changing VM to call SetErrorMode() during startup to prevent these promts from appearing. -- Best regards, Igor Stasenko AKA sig.

Oct. 13, 2010

Re: [Pharo-project] Fwd: License question

by Schwab,Wilhelm K

Paolo, "It only blew up in your face, because you didn't make a totally informed decision upfront. " You seem very willing to blame and insult me, but not to consider that the license carries consequences of suppressing release of code. My decision was very informed. The question now is to what extent I can release a binding to GSL without losing control over years of hard work that are not conceptually dependent on GSL. What you describe as freedom can also be seen as an attempt to control others and limit their freedom. The "GPL compatible" loophole is potentially interesting. Are there any examples of that approach? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Wednesday, October 13, 2010 10:30 AM To: Pharo Development Subject: [Pharo-project] Fwd: License question Begin forwarded message: > From: Paolo Bonzini <bonzini(a)gnu.org> > Date: October 13, 2010 3:38:49 PM GMT+02:00 > To: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > Cc: "Fitzell, Julian" <jfitzell(a)cincom.com>, "stephane.ducasse(a)inria.fr" <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] License question > > On 10/13/2010 02:46 PM, Schwab,Wilhelm K wrote: >> Paolo, >> >> The language is not childish; it is a valid expression of how this >> looks to others; I know, because I had it blow up in my face. > > It only blew up in your face, because you didn't make a totally informed > decision upfront. The GPL FAQ can be a tough read, but it is really complete and helpful. It's not legally binding, but it's written by people who are experts and try to cover as many cases as possible, and . > >> After reading your "clone the API, then you can run fast as GPL or >> slow as MIT," I am more than ever aware of just how on the mark that >> characterization might be. > > Note that nothing forbids you from extending the "slow MIT" part until > it's as fast as the GPL version and effectively obsoletes it. It's just > basic software engineering that you'll first make things work, then > make things fast. > >> Another indication of the extent of the problems with/from GPL >> arises from my planned use of the Pharo Inbox. > > That's not a problem with/from GPL. That's a conscious choice from the > Pharo people, who decided to restrict the Inbox to only accept things > with a particular license. It's not good or wrong, it's simply a > decision that you have to live with. > >> One solution would be to clone and release just enough of the wrapper >> set to help people to roll their own wrappers, which might eventually >> spawn a clean-roomed set of wrappers. A good MIT library will >> eventually appear, and when it does, I want to be able to move my >> higher level code to it. > > Ok, that's fine---making provisions for the future is totally understandable and not childish at all. But then, it doesn't require the usage of language such as "infect" or "virus", either. :) > > The good news is that you can do it. See this other point from the GPL FAQ: > > If a library is released under the GPL (not the LGPL), does that > mean that any program which uses it has to be under the GPL or a > GPL-compatible license? > > Yes, because the program as it is actually run includes the library. > > Note how it says "GPL-compatible" license. Right above this, it says > > The GPL says that the whole combined program has to be released > under the GPL. [...] > > But you can give additional permission for the use of your code. > You can, if you wish, release your program under a license which is > more lax than the GPL but compatible with the GPL. > > So you can release your bindings now and put it under the X11/MIT license. However, I'd still add a README statement specifying that everything using the bindings will also use GSL, and so will have to respect the GPL (when distributed). You can quote the GPL FAQ and highlight "GPL-compatible". > > I can understand if there were some resistance from the Pharo > people about putting this in the main image, however. So, I still suggest that you release your library from your website or from SqueakSource. > > -*- > > As an aside, the GPL is not alone in putting restrictions on redistributions, but it does so for a specific end, which is to maximize the users' freedom. This includes end users, not only developers. > > Take instead Microsoft's license on sample source code, which says you cannot distribute any derivative work in source code. Personally I prefer something that forces me to help people learn, than something that forbids me from doing so. > > I hope this helps you in making a conscious choice, and also in trying to understand my position. > > Paolo _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 13, 2010

Re: [Pharo-project] modal windows and unit tests

by Lukas Renggli

>> There are also some basic things that would need some adjustment as I >> see it. I think core or basic classes and models shouldn't make any >> assumptions about the UI or even if there is an UI at all. > > YESSSssssssss.... and a minicore will help /force us to do that Â (imagine an hudson script blocked because of a nice popup) Consider that this is not the UI framework that should decide to open a dialog or not. If somebody tells morphic to open a window it should open it otherwise you break all kinds of assumptions. If a user wants to support multiple UI frameworks (or the possibility to disable certain UI actions), then he needs to take appropriate action himself. OB for example uses notifications for all UI interactions that are captured either by a morphic handler (by default), a web handler (if you use the web interface), or by a test handler (that builds a fake UI that doesn't display anything but gives you a nice model to exercise the UI). Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 13, 2010

Re: [Pharo-project] modal windows and unit tests

by StÃ©phane Ducasse

On Oct 13, 2010, at 3:04 PM, Alexander LazareviÄ wrote: > There are also some basic things that would need some adjustment as I > see it. I think core or basic classes and models shouldn't make any > assumptions about the UI or even if there is an UI at all. YESSSssssssss.... and a minicore will help /force us to do that (imagine an hudson script blocked because of a nice popup) > So things like Object inform: aString would be something I'd rather > see to disappear. Yes Alexander, this is years that I want that. In fact we started pharo exactly for these kinds of reasons. Getting a clean and cool system. Any code going in that direction is welcome and will be warmly considered. > Or Class rename: aString, which kindly pops up a Dialog to inform the > "user" when there are still references in Undeclared. I think that > check should better move to the sending method in Browser renameClass, > where chances are very high that a real user initiated the rename of a > class and not some filein. > > Alex > > 2010/10/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I think that we will have to reconsider a lot of the infrastructure decision and the hudson server will kick us >> >> Stef >> >> On Oct 12, 2010, at 10:45 PM, Alexander LazareviÄ wrote: >> >>> I was just looking at something similar. >>> I guess for modal windows that are a kind of DialogWindow something >>> like this should work >>> >>> [UIManager default confirm: 'Got milk?'] >>> on: ProvideAnswerNotification >>> do: [:ex | ex resume: (ex messageText = 'Got milk?')] >>> >>> But which modal windows do pop up in your scenario, that do not send a >>> notification? >>> >>> Regards, >>> Alex >>> >>> 2010/10/12 Alexandre Bergel <alexandre(a)bergel.eu>: >>>> Hi! >>>> >>>> A modal window is pop up by one of my tests. Is there a way to capture this situation and simply remove the modal window? >>>> Apparently, no notification is raised... >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 13, 2010

Re: [Pharo-project] Issue 3099: Create method in the debugger does not provide getters/setters implementations

by StÃ©phane Ducasse

+1 We are nice and taking on our time to fix problems but if you do it directly on the current unstable version you will speed up the integration. On Oct 13, 2010, at 2:34 PM, Igor Stasenko wrote: > 2010/10/13 Hernan Wilkinson <hernan.wilkinson(a)10pines.com>: >> No... I have 1.1, is 1.2 released? I have no problem to migrate it to 1.2, >> let me know > > 1.2 is a bleeding-edge under-development image. > > IMO, If you want to add new feature(s) to future release of pharo, > then you need to always work with latest available/updated image to make sure > your changes working w/o problem and do not interfere with other stuff. >

Oct. 13, 2010

[Pharo-project] Fwd: License question

by StÃ©phane Ducasse

Begin forwarded message: > From: Paolo Bonzini <bonzini(a)gnu.org> > Date: October 13, 2010 3:38:49 PM GMT+02:00 > To: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > Cc: "Fitzell, Julian" <jfitzell(a)cincom.com>, "stephane.ducasse(a)inria.fr" <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] License question > > On 10/13/2010 02:46 PM, Schwab,Wilhelm K wrote: >> Paolo, >> >> The language is not childish; it is a valid expression of how this >> looks to others; I know, because I had it blow up in my face. > > It only blew up in your face, because you didn't make a totally informed > decision upfront. The GPL FAQ can be a tough read, but it is really complete and helpful. It's not legally binding, but it's written by people who are experts and try to cover as many cases as possible, and . > >> After reading your "clone the API, then you can run fast as GPL or >> slow as MIT," I am more than ever aware of just how on the mark that >> characterization might be. > > Note that nothing forbids you from extending the "slow MIT" part until > it's as fast as the GPL version and effectively obsoletes it. It's just > basic software engineering that you'll first make things work, then > make things fast. > >> Another indication of the extent of the problems with/from GPL >> arises from my planned use of the Pharo Inbox. > > That's not a problem with/from GPL. That's a conscious choice from the > Pharo people, who decided to restrict the Inbox to only accept things > with a particular license. It's not good or wrong, it's simply a > decision that you have to live with. > >> One solution would be to clone and release just enough of the wrapper >> set to help people to roll their own wrappers, which might eventually >> spawn a clean-roomed set of wrappers. A good MIT library will >> eventually appear, and when it does, I want to be able to move my >> higher level code to it. > > Ok, that's fine---making provisions for the future is totally understandable and not childish at all. But then, it doesn't require the usage of language such as "infect" or "virus", either. :) > > The good news is that you can do it. See this other point from the GPL FAQ: > > If a library is released under the GPL (not the LGPL), does that > mean that any program which uses it has to be under the GPL or a > GPL-compatible license? > > Yes, because the program as it is actually run includes the library. > > Note how it says "GPL-compatible" license. Right above this, it says > > The GPL says that the whole combined program has to be released > under the GPL. [...] > > But you can give additional permission for the use of your code. > You can, if you wish, release your program under a license which is > more lax than the GPL but compatible with the GPL. > > So you can release your bindings now and put it under the X11/MIT license. However, I'd still add a README statement specifying that everything using the bindings will also use GSL, and so will have to respect the GPL (when distributed). You can quote the GPL FAQ and highlight "GPL-compatible". > > I can understand if there were some resistance from the Pharo > people about putting this in the main image, however. So, I still suggest that you release your library from your website or from SqueakSource. > > -*- > > As an aside, the GPL is not alone in putting restrictions on redistributions, but it does so for a specific end, which is to maximize the users' freedom. This includes end users, not only developers. > > Take instead Microsoft's license on sample source code, which says you cannot distribute any derivative work in source code. Personally I prefer something that forces me to help people learn, than something that forbids me from doing so. > > I hope this helps you in making a conscious choice, and also in trying to understand my position. > > Paolo

Oct. 13, 2010

[Pharo-project] Fwd: License question

by StÃ©phane Ducasse

Begin forwarded message: > From: "Schwab,Wilhelm K" <bschwab(a)anest.ufl.edu> > Date: October 13, 2010 2:46:31 PM GMT+02:00 > To: Paolo Bonzini <bonzini(a)gnu.org> > Cc: "Fitzell, Julian" <jfitzell(a)cincom.com>, "stephane.ducasse(a)inria.fr" <stephane.ducasse(a)inria.fr> > Subject: RE: [Pharo-project] License question > > Paolo, > > The language is not childish; it is a valid expression of how this looks to others; I know, because I had it blow up in my face. I am fairly content to use GSL for its feature set and working around its foibles, only because I use it internally and GPL is not a concern. I got a cold dose of reality in the form of resistance from other programmers - some of whom see the license as a legal virus. After reading your "clone the API, then you can run fast as GPL or slow as MIT," I am more than ever aware of just how on the mark that characterization might be. > > Another indication of the extent of the problems with/from GPL arises from my planned use of the Pharo Inbox. Put the code in there, and it's MIT; that's good. But what mess does that cause with a binding to something that is GPL? The answer is not to change the Pharo license, it is to exclude GPL code. I can put something on my web site and allow people to grab it from there. > > The base of the GSL binding is (from memory) 100+ structure definitions (most of which are correct in spirit but not yet tested) and 1800+ function definitions. It ends up being something like 20,000 things that have to be named and typed. They are not much good without wrappers that help with memory management and control flow. I would like to make at least some of the wrapper functionality available, but I am not willing to GPL it for fear of future problems using my own code. If you are telling me that anything that directly or indirectly calls GPL code becomes GPL on release, that will impact how much of the code I can release. One solution would be to clone and release just enough of the wrapper set to help people to roll their own wrappers, which might eventually spawn a clean-roomed set of wrappers. A good MIT library will eventually appear, and when it does, I want to be able to move my higher level code to it. I will not hobble that goal for short-term gains. Childish? Quite the opposite. > > Bill > > > > ________________________________________ > From: Paolo Bonzini [paolo.bonzini(a)gmail.com] On Behalf Of Paolo Bonzini [bonzini(a)gnu.org] > Sent: Wednesday, October 13, 2010 3:50 AM > To: Schwab,Wilhelm K > Cc: Fitzell, Julian; stephane.ducasse(a)inria.fr > Subject: Re: [Pharo-project] License question > > On 10/12/2010 08:13 PM, Schwab,Wilhelm K wrote: >> nor do I want my code, other than the binding itself, affected by >> GPL. > > Code that uses the binding is obviously affected by the GPL, just like > if you used GSL directly in C. It's not like using a different > programming language is a magic wand that makes the GPL disappear. > > However, your code that does not use the binding will not be affected by > the GPL. Code doesn't fall under the GPL just because it lived for a > short time in the same image. In particular: > > 1) the GPL does not kick in until you distribute the code. As long as > GPL and non-GPL (or even GPL-incompatible) code resides in a private > image (or even circulates within an institution such as a company) there > is no distribution and the GPL is not involved at all. > > 2) let's say you juxtapose GPL and X11-licensed (MIT) code in the same > image. The non-GPL code doesn't use your bindings or any other GPL > code, it's just placed together in the same image. This time you > distribute the image, and in order to do so you must follow the GPL. > However, you can still extract the X11-licensed code and distribute > _that_ code under its own original license, or even as proprietary code > since _that_ code's license is what counts. > >> It would be a shame to have to limit the a release to just the >> binding, but if GPL starts to infect anything that connects to the >> binding > > It doesn't "start to infect". Please do not use such childish language. > The GPL simply "applies" to anything that connects to the binding, > just like it would "apply" to anything that uses GSL using the C interface. > > You probably would not say that using proprietary source code in Squeak > or Pharo "infects" it with a proprietary license. You'd simply say "you > have to respect the license of the proprietary source code", or you > violate the copyright owner's rights. The GPL is absolutely no > different. It tells you what you can do and what you cannot do. > > Very frankly: if you think the GPL has "infected" something, well, it > didn't do anything on its own, it was _you_ who did something stupid. > > Paolo

Oct. 13, 2010

Re: [Pharo-project] Issue 3099: Create method in the debugger does not provide getters/setters implementations

by Hernan Wilkinson

Done it on CreateMethodDoesNotGenerateGettersOrSetters-HernanWilkinson.5 On Wed, Oct 13, 2010 at 10:46 AM, Hernan Wilkinson < hernan.wilkinson(a)10pines.com> wrote: > ok, doing the migration now... > One question, where should I put the test class? I mean, I created the > class DynamicMessageImplementor at "Tools-Debugger", where should I put > DynamicMessageImplementorTest ? > I saw there are some packages like ToolsTest-Inspector or > ToolsTest-MessageTally, but I think it does not make sense to create a > package per test class... > > > On Wed, Oct 13, 2010 at 9:31 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> unstable is available on the forge and this is important to develop on it >> else we have a lot of problem merging. >> >> Stef >> >> On Oct 13, 2010, at 1:18 PM, Hernan Wilkinson wrote: >> >> > No... I have 1.1, is 1.2 released? I have no problem to migrate it to >> 1.2, let me know >> > >> > On Wed, Oct 13, 2010 at 3:06 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> > Thanks hernan >> > did you do that with the lastest 1.2? >> > >> > Stef >> > >> > On Oct 13, 2010, at 3:35 AM, Hernan Wilkinson wrote: >> > >> > > Hi, >> > > I added an issue (an enhancement really) and also uploaded the code >> for it. >> > > The enhancement is that when you press "Create" on the debugger, it >> would be nice if the generated method could realize that the message is a >> getter or setter and provide an implementation accordingly. >> > > I also refactor the method #createMethodStub in Message. To do so I >> create the class DynamicMessageImplementor and its test >> DynamiMessageImplementorTest. >> > > >> > > I hope you like it! >> > > Hernan. >> > > >> > > -- >> > > HernÃ¡n Wilkinson >> > > Agile Software Development, Teaching & Coaching >> > > Mobile: +54 - 911 - 4470 - 7207 >> > > email: hernan.wilkinson(a)10Pines.com >> > > site: http://www.10Pines.com >> > > >> > > _______________________________________________ >> > > 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 >> > >> > >> > >> > -- >> > HernÃ¡n Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: hernan.wilkinson(a)10Pines.com >> > site: http://www.10Pines.com >> > >> > _______________________________________________ >> > 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 >> > > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com <http://www.10pines.com/>* > > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 13, 2010

Re: [Pharo-project] Issue 3099: Create method in the debugger does not provide getters/setters implementations

by Hernan Wilkinson

ok, doing the migration now... One question, where should I put the test class? I mean, I created the class DynamicMessageImplementor at "Tools-Debugger", where should I put DynamicMessageImplementorTest ? I saw there are some packages like ToolsTest-Inspector or ToolsTest-MessageTally, but I think it does not make sense to create a package per test class... On Wed, Oct 13, 2010 at 9:31 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > unstable is available on the forge and this is important to develop on it > else we have a lot of problem merging. > > Stef > > On Oct 13, 2010, at 1:18 PM, Hernan Wilkinson wrote: > > > No... I have 1.1, is 1.2 released? I have no problem to migrate it to > 1.2, let me know > > > > On Wed, Oct 13, 2010 at 3:06 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > > Thanks hernan > > did you do that with the lastest 1.2? > > > > Stef > > > > On Oct 13, 2010, at 3:35 AM, Hernan Wilkinson wrote: > > > > > Hi, > > > I added an issue (an enhancement really) and also uploaded the code > for it. > > > The enhancement is that when you press "Create" on the debugger, it > would be nice if the generated method could realize that the message is a > getter or setter and provide an implementation accordingly. > > > I also refactor the method #createMethodStub in Message. To do so I > create the class DynamicMessageImplementor and its test > DynamiMessageImplementorTest. > > > > > > I hope you like it! > > > Hernan. > > > > > > -- > > > HernÃ¡n Wilkinson > > > Agile Software Development, Teaching & Coaching > > > Mobile: +54 - 911 - 4470 - 7207 > > > email: hernan.wilkinson(a)10Pines.com > > > site: http://www.10Pines.com > > > > > > _______________________________________________ > > > 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 > > > > > > > > -- > > HernÃ¡n Wilkinson > > Agile Software Development, Teaching & Coaching > > Mobile: +54 - 911 - 4470 - 7207 > > email: hernan.wilkinson(a)10Pines.com > > site: http://www.10Pines.com > > > > _______________________________________________ > > 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 > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>*

Oct. 13, 2010

Re: [Pharo-project] modal windows and unit tests

by Alexandre Bergel

cool! Alexandre On 13 Oct 2010, at 10:34, Alexander LazareviÄ wrote: > Just created an issue. Thanks. > > Alex > > 2010/10/13 Alexandre Bergel <alexandre(a)bergel.eu>: >> Agree. >> Maybe this should be kept in an issue if not already. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 13, 2010

Re: [Pharo-project] modal windows and unit tests

by Alexander LazareviÄ

Just created an issue. Thanks. Alex 2010/10/13 Alexandre Bergel <alexandre(a)bergel.eu>: > Agree. > Maybe this should be kept in an issue if not already.

Oct. 13, 2010