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

[Pharo-project] I would like to have feedback on Compiler PopUp plague
by StÃ©phane Ducasse Sept. 27, 2009

Sept. 27, 2009

http://code.google.com/p/pharo/issues/detail?id=1224 if somebody can have a look about what I did it would be cool stef

1 0

[Pharo-project] Fwd: Issue 1129 in pharo: UIManager #request: and #multilineRequest do not distinguish between empty and cancel
by StÃ©phane Ducasse Sept. 27, 2009

Sept. 27, 2009

Hi I kind of agree on this one. So what is the preferred solution. Now this is important to be able to distinguish an empty string from a cancel. Stef Begin forwarded message: > From: codesite-noreply(a)google.com > Date: September 26, 2009 5:07:13 AM CEDT > To: stephane.ducasse(a)gmail.com > Subject: Issue 1129 in pharo: UIManager #request: and > #multilineRequest do not distinguish between empty and cancel > > > Comment #17 on issue 1129 by andreas.raab: UIManager #request: and > #multilineRequest do not distinguish between empty and cancel > http://code.google.com/p/pharo/issues/detail?id=1129 > > Can I ask to reopen this issue before 1.0 goes out? It introduces a > superficial > incompatibility between Pharo and Squeak or other external code that > is really > unecessary. There are two excellent alternatives: > > 1) Extend the existing protocol, by means of, e.g, > result := UIMananger default request: 'What is your name?' onCancel: > ["whatever"]. > This allows for a simple and straightforward use in cases where one > needs to > distinguish between cancel and empty return and it trivially extends > to uses of > multiLineRequest: as well re requestPassword:. > > 2) Alternatively, introduce a new protocol and deprecate the old > one. For example: > result := UIManager default ask: 'What is your name?'. > With a changed protocol any breakage is straightforward and obvious > and not subtle > and in corner cases that may not be tested for by some external > code. Plus, it is > possible to provide a compatibility layer where necessary. > > From my point of view both of the above are far better solutions and > do not require > any additional work. > > > -- > You received this message because you are listed in the owner > or CC fields of this issue, or because you starred this issue. > You may adjust your issue notification preferences at: > http://code.google.com/hosting/settings

2 2

[Pharo-project] key pressed
by Tudor Girba Sept. 27, 2009

Sept. 27, 2009

Hi, How can I check whether a certain key is pressed (for example, a modifier like Shift)? Cheers, Doru -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."

4 4

[Pharo-project] pharo1.0-10451-BETAweb09.09.3 in FireFox
by Dennis Schetinin Sept. 27, 2009

Sept. 27, 2009

I can't log in at the 'main' page (http://127.0.0.1:8080/seaside/pier) in Pier. It just ignores all the inputs (both correct and incorrect) simply redirecting from input form back to the main page. But from the Blog or About page it works correctly. It's all using FireFox 3.5.3. With Chrome it's ok everywhere, including 'main' page... What can be the cause of the problem? -- Dennis Schetinin

3 2

[Pharo-project] OSProcess question
by Schwab,Wilhelm K Sept. 26, 2009

Sept. 26, 2009

I see various ways to run something, none of which are quite what I want. The objective is to run openssl in a particular directory. I have no need to make this portable (unless you mean running on all of Ubuntu, Debian, Slackware, etc. <g>), so #forkAndExec:...workingDirectory: would almost be ok, **but**, I need to wait around for the result. In truth, there are a few things that have to happen in sequence; perhaps I could simply write multiple lines to the command string. Still, in the interest of idealism, it would be nice to run the commands on other than the Pharo main thread (no sense diving into something that might not return[*]), and to know when the work is done, and to get the different steps to happen in sequence. There was mention of tests for OSProcess (which might provide clues), but I have not been able to find them. Any hints? Bill [*] insert Windows joke here :)

3 5

[Pharo-project] ClosureTests remove expected failures
by Michael Roberts Sept. 26, 2009

Sept. 26, 2009

Compiler-MikeRoberts.132 in Inbox Remove unexpected failures since the tests now pass with Eliot's latest batch of closure fixes. thanks, Mike

2 2

[Pharo-project] [update] #10460
by StÃ©phane Ducasse Sept. 26, 2009

Sept. 26, 2009

10460 ----- - Issue 1246: MethodPropertiesTests expected failures - Issue 1247: ClosureTests remove expectedFailures - Issue 1242: MessageNotUnderstood: ProjectViewMorph class>>serviceOpenProjectFromFile - Issue 1248: Orange Transcript - Issue 1240: Mantis 1035 : resizing a polygonMorph contained in a proportional layout is weird - Issue 1232: Delay bug a further step towards 1.0 stef

1 0

[Pharo-project] MethodPropertiesTests mark expected failures
by Michael Roberts Sept. 26, 2009

Sept. 26, 2009

http://code.google.com/p/pharo/issues/detail?id=1246 KernelTests-MikeRoberts.151 in Inbox thanks, Mike

1 0

[Pharo-project] LGPL considered crippling license :)
by Igor Stasenko Sept. 26, 2009

Sept. 26, 2009

I haven't visited the Orge site long ago, i found an interesting news, that they switching license to MIT! The motivation & conclusions why they decided to switch are very interesting: --- citation --- Wonât this mean people can ârip offâ OGRE in proprietary software? The LGPL already allowed OGRE to be used in proprietary software, and this is something weâve always encouraged. The main difference between the LGPL and the MIT License is that there is no requirement to release modified source code; only to include our copyright and the MIT license text in the final product. While not requiring modified source to be released might initially seem like giving up an important motivator to contribute code back to the community, weâve noticed something in recent years: 99% of useful code contributions come from people who are motivated to participate in the project regardless of what the license tells them they have to do. Itâs our experience that a certain percentage of the user community will always participate and contribute back, and therefore encouraging adoption via simpler licensing is likely to result in more contributions overall than coersion via complex and restrictive licensing does. In addition, people who are internally motivated to participate tend to provide much higher quality and more usable contributions than those who only do it because they are forced to. --- citation --- you can read the full article here: http://www.ogre3d.org/2009/09/15/ogre-will-switch-to-the-mit-license-from-1… P.S. i found it a very good sign, that more and more open-source communities gradually moving towards more permissive license, as MIT is. -- Best regards, Igor Stasenko AKA sig.

2 1

Sept. 26, 2009

10459 ----- rollbacked and merged Kernel-StephaneDucasse.405, SystemSupport.StephaneDucasse.89, Tools-StephaneDucasse.202 - Issue 1219: Left over of uniClasses...in Object Object class>>newUserInstance Object class>>instanceOfUniqueClass Object class>>instanceOfUniqueClassWithInstVarString: instVarString andClassInstVarString: classInstVarString Object class>>categoryForUniclasses Object class>>newUniqueClassInstVars: instVarString classInstVars: classInstVarString - Issue 1223: reduce message text on full name prompt - Issue 1222: edit Repository information->cancel fails. UIManager#multiLineRequest:centerAt:initialAnswer:answerHeight: returns nil - Issue 1199: Debug log is overwritten with each error - Issue 1233: Needs changes after fix 1129 Fix on issue #1129 changed the interface of UIManager. We have to change each user of the #request: method and its friends. Enjoy

1 0