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

[Pharo-project] How about atomic value-swap bytecode?
by Igor Stasenko Oct. 13, 2010

Oct. 13, 2010

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. ] So, i thought , if we could have a special bytecode, then we could write something like: | var1 var2 | var1 :=: var2. So, VM will guarantee that values of var1 and var2 will be swapped atomically, and completely thread-safe. var1 and var2 could be either temps or instance variables, but of course not arguments, since they are not assignable. One thing i don't like, that it will need to introduce a new syntax for atomic-value-swap operator - :=: Or, maybe just reserve a special keyword selector (which is recognized by compiler), so var1 __atomicSwapWith: var2 so it will look like a regular smalltalk syntax, except that its not a message send, but a low-level operation instead. -- Best regards, Igor Stasenko AKA sig.

4 8

[Pharo-project] Iliad 0.9.1 released
by Nicolas Petton Oct. 13, 2010

Oct. 13, 2010

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

1 0

[Pharo-project] OCompletion usability
by Nicolas Cellier Oct. 13, 2010

Oct. 13, 2010

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

2 1

[Pharo-project] FreeType fonts scan annoyance on windows
by Igor Stasenko Oct. 13, 2010

Oct. 13, 2010

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.

1 0

[Pharo-project] Fwd: License question
by StÃ©phane Ducasse Oct. 13, 2010

Oct. 13, 2010

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

2 1

Re: [Pharo-project] modal windows and unit tests
by StÃ©phane Ducasse Oct. 13, 2010

Oct. 13, 2010

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

2 1

Re: [Pharo-project] Issue 3099: Create method in the debugger does not provide getters/setters implementations
by StÃ©phane Ducasse Oct. 13, 2010

Oct. 13, 2010

+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. >

1 0

[Pharo-project] Fwd: License question
by StÃ©phane Ducasse Oct. 13, 2010

Oct. 13, 2010

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

1 0

Re: [Pharo-project] Issue 3099: Create method in the debugger does not provide getters/setters implementations
by StÃ©phane Ducasse Oct. 13, 2010

Oct. 13, 2010

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

2 2

Re: [Pharo-project] modal windows and unit tests
by StÃ©phane Ducasse Oct. 13, 2010

Oct. 13, 2010

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

4 5

[Pharo-project] modal windows and unit tests
by Alexandre Bergel Oct. 13, 2010

Oct. 13, 2010

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

3 7

Re: [Pharo-project] Issue 3099: Create method in the debugger does not provide getters/setters implementations
by StÃ©phane Ducasse Oct. 13, 2010

Oct. 13, 2010

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

3 2

[Pharo-project] Fwd: License question
by StÃ©phane Ducasse Oct. 13, 2010

Oct. 13, 2010

Begin forwarded message: > From: Paolo Bonzini <bonzini(a)gnu.org> > Date: October 13, 2010 9:51:01 AM 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/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

1 0

[Pharo-project] is Squeaksource down?
by Guillermo Polito Oct. 13, 2010

Oct. 13, 2010

:( Can someone check it? Thanks!

4 3

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave
by mkobetic＠gmail.com Oct. 13, 2010

Oct. 13, 2010

"Sven Van Caekenberghe"<sven(a)beta9.be> wrote: > >> I also found an issue: the process in XTTransformWriteStream doesn't > >> terminate. If you run the tests, you'll get 12 lingering processes. > > > > I don't see that happening in Pharo 1.1. Normally the process should end normally when the stream is closed (the close synchronizes with the process via the closeReady semaphore). Maybe there's a missing close somewhere in the test suite ? > > I have these hanging processes as well (you probably know that the Process Browser does not auto update by default ?), I've never seen unit tests that did that... OK, I can see this on VW side too. The following test cases fail to close the transform write stream (against our own advice, sic): Xtreams.ReadingWritingTest>>#testWriteRejecting Xtreams.ReadingWritingTest>>#testWriteSelecting Xtreams.ReadingWritingTest>>#testWriteTransformHexToByte Xtreams.ReadingWritingTest>>#testWriteTransforming1into2 Xtreams.ReadingWritingTest>>#testWriteTransforming2into1 I'll make the fixes on VW side.

1 0

[Pharo-project] Issue 3099: Create method in the debugger does not provide getters/setters implementations
by Hernan Wilkinson Oct. 13, 2010

Oct. 13, 2010

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 <http://www.10pines.com/> *

1 0

[Pharo-project] [update 1.2] #12193
by StÃ©phane Ducasse Oct. 12, 2010

Oct. 12, 2010

12193 ----- - Issue 3096: FreeType problem with new finalization. Thanks Igor Stasenko. - Issue 2999: Object>>isConflict. Moving isConflict from Object to MCPacthOperation. - Issue 3085: StringHolder should not be in Kernel Stef

1 0

[Pharo-project] Code annotations? Why they broken again?
by Igor Stasenko Oct. 12, 2010

Oct. 12, 2010

Hello, i just found that annotation panes is not updating in latest pharo. Digging through it , i found that it no longer receives #annotation notification (through #update:) but #contents instead. Fix already in inbox, see issue #3098 P.S. Is it only me, stubborn one, who using annotation panes among pharoers, that nobody else noticed it? -- Best regards, Igor Stasenko AKA sig.

1 0

Oct. 12, 2010

thanks! On Oct 12, 2010, at 7:08 PM, Igor Stasenko wrote: > In Pharo-INBOX > > Name: FreeType-Igor_Stasenko.536 > Author: Igor.Stasenko > Time: 12 October 2010, 8:07:50 pm > UUID: fa9746fa-e253-7948-8bab-799ea9fba754 > Ancestors: FreeType-StephaneDucasse.535 > > - removed weak registry subclass, > but preserving the same semantics as before (guard against duplicating handles) > > On 12 October 2010 18:19, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> yes >> >> >> On Oct 12, 2010, at 4:51 PM, Gary Chambers wrote: >> >>> Is in core now I believe. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Tuesday, October 12, 2010 2:29 PM >>> Subject: Re: [Pharo-project] FreeType and finalization >>> >>> >>>> I can modify Freetype to not use subclass of weakregistry, >>>> and still guarantee non-duplication. >>>> Is Freetype a separate maintained package, or its part of Pharo core? >>>> >>>> >>>> On 12 October 2010 16:25, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >>>>> Indeed... never seen that error hence proposal for simplest solution. >>>>> >>>>> Regards, Gary >>>>> >>>>> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >>>>> To: <Pharo-project(a)lists.gforge.inria.fr> >>>>> Sent: Tuesday, October 12, 2010 1:21 PM >>>>> Subject: Re: [Pharo-project] FreeType and finalization >>>>> >>>>> >>>>>> 2010/10/12 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>>>>> >>>>>>> Hi all, I've encountered a problem with FreeType with respect to the new >>>>>>> finalization scheme. >>>>>>> http://code.google.com/p/pharo/issues/detail?id=3096 >>>>>>> Regards, Gary >>>>>>> >>>>>> >>>>>> FT2HandleRegistry overrides following method: >>>>>> >>>>>> add: anObject >>>>>> "Add anObject to the receiver. Store the object as well as the >>>>>> associated executor." >>>>>> | executor dup | >>>>>> executor := anObject executor. >>>>>> dup := nil. >>>>>> self protected:[ >>>>>> dup := valueDictionary detect: [ :v | v handle = executor handle ] >>>>>> ifNone: [ ]. >>>>>> valueDictionary at: anObject put: executor. >>>>>> ]. >>>>>> dup ifNotNil: [ self error: 'Duplicate object added!'. self remove: >>>>>> anObject ]. >>>>>> ^anObject >>>>>> >>>>>> >>>>>> As i see, the intent is to prevent registering a same handle twice, >>>>>> so in own turn, when time will come, a #finalize won't attempt to >>>>>> destroy same handle twice. >>>>>> >>>>>> The proposed fix (as you wrote in issue tracker) >>>>>> >>>>>> registry >>>>>> ^Registry ifNil: [ Registry := WeakRegistry new] >>>>>> >>>>>> appears to fix the problem... >>>>>> >>>>>> But apparently its not the same as in original. >>>>>> Okay, but since we never seen the error: 'Duplicate object added!', >>>>>> then i think it may work without it :) >>>>>> >>>>>> Still, it would be good to know, how handles are created, and what the >>>>>> chances that they could be duplicated. >>>>>> >>>>>> -- >>>>>> 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 >>> >>> >>> _______________________________________________ >>> 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

1 0

Oct. 12, 2010

Damien we can create an inria project like that we do not rely on external infrastructure. This will be good for us anyway. Stef On Oct 12, 2010, at 6:41 PM, Damien Pollet wrote: > On Mon, Oct 11, 2010 at 17:25, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >>> Excellent, can I also push the Seaside Book there? > > Just a heads upâ¦ with all the translations we are already using 2/3 of > the space for a free account :) > >> If you want. Now I do not see the interest of git when we use it as svn. And I would prefer to host the book on an inria server >> because I know that this is backup by someboyd else than me. > > It shouldn't be too hard to mirror the github repos to git-enabled > project on the gforge. > I just have to check how post-commit hooks workâ¦ > >> and for a book I do not want to fork it (or people can fork it but I do not care of what they will do with their fork). > > With SVN, forking is a technical issue (and a tough one because it's > difficult to merge back). > With Git, forking is a political issue, which it should be (and an > easy one because you just have to be clean which repo is the official > one). > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] Xtreams files
by Nicolas Cellier Oct. 12, 2010

Oct. 12, 2010

I added a hook to Xtreams files this evening. The hook by now is in FileDirectory (no comment... I'll be happy when a replacement is integrated in Squeak/Pharo). ((FileDirectory default / 'toto.txt') writing encoding: #ascii) write: 'hello world'; close. ((FileDirectory default / 'toto.txt') reading encoding: #ascii) rest. I didn't hook into StandardFileStream, but rather a simplified version of David Lewis IOHandle. I separated this stuff in Xtreams-SqueakExternals. Anyway, this is not really related to Xtreams, most of the functionality should be in core (apart reading/writing/appending which might better return in Xtreams-Terminals). I also slighlty modified XTFileReadStream and XTFileWriteStream to fit some Squeak specific API. Maybe I could have just used the VW API and provide compatibility layer... We'll see later. Nicolas

1 0

Oct. 12, 2010

Stef

4 4

Oct. 12, 2010

yes On Oct 12, 2010, at 4:51 PM, Gary Chambers wrote: > Is in core now I believe. > > Regards, Gary > > ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Tuesday, October 12, 2010 2:29 PM > Subject: Re: [Pharo-project] FreeType and finalization > > >> I can modify Freetype to not use subclass of weakregistry, >> and still guarantee non-duplication. >> Is Freetype a separate maintained package, or its part of Pharo core? >> >> >> On 12 October 2010 16:25, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: >>> Indeed... never seen that error hence proposal for simplest solution. >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Tuesday, October 12, 2010 1:21 PM >>> Subject: Re: [Pharo-project] FreeType and finalization >>> >>> >>>> 2010/10/12 Gary Chambers <gazzaguru2(a)btinternet.com>: >>>>> >>>>> Hi all, I've encountered a problem with FreeType with respect to the new >>>>> finalization scheme. >>>>> http://code.google.com/p/pharo/issues/detail?id=3096 >>>>> Regards, Gary >>>>> >>>> >>>> FT2HandleRegistry overrides following method: >>>> >>>> add: anObject >>>> "Add anObject to the receiver. Store the object as well as the >>>> associated executor." >>>> | executor dup | >>>> executor := anObject executor. >>>> dup := nil. >>>> self protected:[ >>>> dup := valueDictionary detect: [ :v | v handle = executor handle ] >>>> ifNone: [ ]. >>>> valueDictionary at: anObject put: executor. >>>> ]. >>>> dup ifNotNil: [ self error: 'Duplicate object added!'. self remove: >>>> anObject ]. >>>> ^anObject >>>> >>>> >>>> As i see, the intent is to prevent registering a same handle twice, >>>> so in own turn, when time will come, a #finalize won't attempt to >>>> destroy same handle twice. >>>> >>>> The proposed fix (as you wrote in issue tracker) >>>> >>>> registry >>>> ^Registry ifNil: [ Registry := WeakRegistry new] >>>> >>>> appears to fix the problem... >>>> >>>> But apparently its not the same as in original. >>>> Okay, but since we never seen the error: 'Duplicate object added!', >>>> then i think it may work without it :) >>>> >>>> Still, it would be good to know, how handles are created, and what the >>>> chances that they could be duplicated. >>>> >>>> -- >>>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2 1

Oct. 12, 2010

> Excellent, can I also push the Seaside Book there? If you want. Now I do not see the interest of git when we use it as svn. And I would prefer to host the book on an inria server because I know that this is backup by someboyd else than me. and for a book I do not want to fork it (or people can fork it but I do not care of what they will do with their fork). > > The main data store remains Pier of course, but we already today keep > the backups and other resources in the SCG SVN. > > Lukas > > > > On 11 October 2010 17:06, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: >> Great Oscar ! How to join the SquareBracketAssociates ? >> >> >> On Mon, Oct 11, 2010 at 4:39 PM, Oscar Nierstrasz >> <oscar.nierstrasz(a)gmail.com> wrote: >>> >>> See: http://github.com/SquareBracketAssociates/ >>> >>> Cheers, >>> - on >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam >> Every DSL ends up being Smalltalk >> http://doesnotunderstand.org/ >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

3 2

Re: [Pharo-project] [squeak-dev] Re: Xtreams port to Squeak - second wave
by mkobetic＠gmail.com Oct. 12, 2010

Oct. 12, 2010

"Levente Uzonyi"<leves(a)elte.hu> wrote: > Okay, I really tracked down the cause of the problem. The tests perform > simple producer-consumer scenarios, but the consumers won't wait at all. > If there's nothing to consume, the test fails. The randomness come from > the scheduler. The server process is started first, the client is the > second. If the server process can produce enough input to the client > process the test will pass. > If you decrease the priority of the client process by one in > #timeout:server:client:, the randomness will be gone and the tests will > reliably pass, because the client won't be able to starve the server. To > avoid false timeouts I had to increase the timeout value to 2000 > milliseconds using SqueakVM. An alternative solution I was thinking about would be to dispense with the processes in default case and simply run the server and client blocks sequentially. The cases where we really need the processes are channels with limited capacity (e.g. Socket or Pipe) where the writer needs to be able to block (when the OS buffers fill up) and let the reader consume some of the output before it continues writing. In these cases there aren't any shared resources so process contention should not be an issue. The other advantage would be that cases with the default behavior would be easier to debug and would not be subject to timeouts. As it is I still get timeouts sporadically even when it's set to 1 second. > I also found an issue: the process in XTTransformWriteStream doesn't > terminate. If you run the tests, you'll get 12 lingering processes. I don't see that happening in Pharo 1.1. Normally the process should end normally when the stream is closed (the close synchronizes with the process via the closeReady semaphore). Maybe there's a missing close somewhere in the test suite ?

2 1