February 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3682 in pharo: multiple undo/redo is broken in 1.2 because of Ocompletion.

by pharo＠googlecode.com

Status: Accepted Owner: aplan...(a)gmail.com Labels: Milestone-1.2 New issue 3682 by aplan...(a)gmail.com: multiple undo/redo is broken in 1.2 because of Ocompletion. http://code.google.com/p/pharo/issues/detail?id=3682 I've found the fix. It has two parts, one part for the core and the second is for ocompletion.

Feb. 7, 2011

Re: [Pharo-project] new Cog VMs available

by Francois Stephany

Hi Eliot, Probably a stupid question but what's the difference between SimpleStackBasedCogit and StackToRegisterMappingCogit ? > new Cog VMs are available, SimpleStackBasedCogit @ > http://www.mirandabanda.org/files/Cog/VM/VM.r2359/ and > StackToRegisterMappingCogit @ > http://www.mirandabanda.org/files/Cog/VM/VM.r2361. I think the new code > generator is ready for prime time now. I fixed a number of bugs over > the past three weeks and we're now using the StackToRegisterMappingCogit > internally at Teleplace.

Feb. 7, 2011

Re: [Pharo-project] Issue 3681 in pharo: [Failing Test] Tests.Release.ReleaseTest.testObsoleteClasses

by pharo＠googlecode.com

Comment #1 on issue 3681 by laurent....(a)gmail.com: [Failing Test] Tests.Release.ReleaseTest.testObsoleteClasses http://code.google.com/p/pharo/issues/detail?id=3681 SLICE-Issue-3681--Failing-Test-TestsReleaseReleaseTesttestObsoleteClasses-LaurentLaffont.1 Add some description for ReleaseTest testObsoleteClasses so we can see it on Hudson log if failing.

Feb. 7, 2011

[Pharo-project] Issue 3681 in pharo: [Failing Test] Tests.Release.ReleaseTest.testObsoleteClasses

by pharo＠googlecode.com

Status: Accepted Owner: laurent....(a)gmail.com New issue 3681 by laurent....(a)gmail.com: [Failing Test] Tests.Release.ReleaseTest.testObsoleteClasses http://code.google.com/p/pharo/issues/detail?id=3681 Pharo 1.2 Remaining: AnObsoleteAutoGeneratedClassForTestingSystemChanges, AnObsoleteMCMockClassG For AnObsoleteAutoGeneratedClassForTestingSystemChanges, to reproduce: 1. Take Pharo 1.2 full from Hudson 2. run ReleaseTest testObsoleteClasses, green 3. run ChangeHooksTest testClassCommentedEvent, green 3. rerun ReleaseTest testObsoleteClasses, red

Feb. 7, 2011

Re: [Pharo-project] Network training

by jannik.laval

Levente, the problem is not the difficulty to recompile the VM... if it is well documented (I do not know here), but I do not want to have my vm that nobody uses with a project that nobody can use. And why would I compile a VM ??? Is it a viable process ? I am not sure. Cheers, Jannik On Feb 6, 2011, at 19:15 , Levente Uzonyi wrote: > On Sat, 5 Feb 2011, Luc Fabresse wrote: > > snip > >> Hi Levente, >> >> Why I am doing Ocean with Noury is: >> >> 1) Network never worked fine for me (NetNameResolver ,...). The API (Image >> side) is not OO (All concerns in Socket: IPV4, IPV6, TCD, UDP, ...). >> We first try to write unit tests and then we planned to redesign the API. >> But it implies to understand well the primitives and it is not EASY at all. >> Some are said old in comments (IPV4 primitives?), some are new (IPV6?),... >> So it is a too HARD to understand this code without doc or explanations >> (and you are right I am also a poor newbie). > > There was an "old" implementation of sockets, where every socket had a single semaphore. The "new" implementation added separate read and write semaphores. I guess this change was around 2005, so you can assume that every VM has the "new" implementation. > > There was another change for IPv6 support.AFAIK CogVMs don't have these primitives, but SqueakVMs do. > >> >> 2) I do not want to hear this sentence anymore: "Oh yes, you use a VM with >> an old version of the socket plugin. You should recompile the VM." >> NO! I CAN'T DO THAT BECAUSE (until recently) RECOMPILING THE VM REQUIRE DEEP >> KNOWLEDGE AND SOME BLACK MAGIC. (Thanks to Igor, Esteban and all others to > > Sorry but this is simply bullshit, the result of some people spreading FUD. Recompiling the VM is easy. I could compile VMs when I was a Squeak newbie. The same applies for writing plugins. > >> prepare a simple process for newbies like me such as checkout and compile). >> >> >> 3) Ocean idea: pull up the network stuff on the image side. use an FFI to >> call OS libs. With this approach I am able to: load new versions of the >> network without changing the VM, in the future directly call the new OS API >> (Grand Central on OSX for asynchronous sockets, --yes network libs >> evolve--...), write more high level code and it is a little bit easier to >> debug it. > > The idea is nice, but I guess the performance will be a lot worse than using a custom plugin. > >> >> Ocean is our vision, perhaps it is wrong but I can not do better. >> It is not as complete as the plugin yet. >> We also plan to use either Alien+OS lib or the plugin as a backend for >> Ocean so the plugin will still be there at the end for those who want it. >> And for this last part, we will certainly need some explanations on the >> primitives in SocketPlugin code. So if you know it well, feel free to >> educate me. > > I don't know it well, but I usually deeply explore the code if I want to know how it works (or how it should work). Googling mailing lists and the squeak wiki used to be helpful too. > > > Levente > >> >> #Luc > > snip >

Feb. 7, 2011

Re: [Pharo-project] Network training

by jannik.laval

Thank you Levente, I will check that, try it and check if it works fine... and write tests. Cheers, Jannik On Feb 6, 2011, at 18:48 , Levente Uzonyi wrote: > On Sat, 5 Feb 2011, jannik.laval wrote: > >> Hi Levente, >> >> Thank you for the answer, but it is not clear for me where is this source code. >> You are saying that the VM includes already something like that, does the 5.7 (non-cog) includes it ? >> And how can I find the source code ? I will try to search on eToys image. > > If you're lucky, then the sourcecode is attached to the tracker issues. If there are only slices, then it'll be a bit harder to find the relevant changes, because you can't diff a slice to the current version. > If none of the above works, then this diff may be helpful: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-December/155685… > > > Levente > >> >> Why was in included in removed from Pharo ? >> >> Jannik >> >> On Feb 4, 2011, at 13:24 , Levente Uzonyi wrote: >> >>> On Fri, 4 Feb 2011, jannik.laval wrote: >>> >>>> Hi, >>>> >>>> I am playing with Network package. >>>> I am giving a practical work to my students, in Java :( >>>> And I am doing the same in Pharo to understand the Network package :))) >>>> >>>> A first question: >>>> I use "NetNameResolver localHostAddress" to retrieve my network address. Now in computers, there are multiple addresses. >>>> I do not find a method to retrieve a collection of my address and it seems to be not possible, because it uses primLocalAddress, which is a primitive returning one local address. >>>> >>>> Does it exist something to have all my ip address? >>> >>> Yes. The network changes that were introduced in Pharo 1.1 and were reverted before the release contained such methods. In theory both the VM side and client side code is ready for this (Etoys uses it on OLPC), but some VMs (e.g. Cog) don't have the latest plugin versions, so the primitives don't work there. >>> >>> >>> Levente >>> >>>> >>>> Thank you, >>>> >>>> >>>> >>>> --- >>>> Jannik Laval >>>> >>>> >>>> >>> >> >> >> >

Feb. 7, 2011

Re: [Pharo-project] Primitive calls in one package

by jannik.laval

I understand your point :), Now, with my problem with Network, we can see that some primitives do not exist in the image of pharo nor squeak. But are inside etoys image.... Where I think that all these images should have the same primitives, because based on same VM. My idea is in that way: how can we maintain primitives and match them with the vm ? Cheers, Jannik On Feb 6, 2011, at 17:47 , Noury Bouraqadi wrote: > I totally agree with Bill. > > Noury > > On 5 fÃ©vr. 2011, at 21:40, Schwab,Wilhelm K wrote: > >> If there is a problem finding primitives, then that probably deserves attention in the browsers. Given that collections, sockets, streams, etc. all use primitives, will likely continue to do so, and will also find competition (Nile, new sockets package, etc.), I think it would be inappropriate to set up a presumption that all primitives lurk in one package. It cannot (or should not) be enforced, and would interfere with evolution. >> >> With respect, -1. >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Laval Jannik [jannik.laval(a)inria.fr] >> Sent: Saturday, February 05, 2011 3:06 PM >> To: Pharo Development >> Subject: [Pharo-project] Primitive calls in one package >> >> Hi, >> >> What is your opinion about having all primitive calls in one package ? >> It would be easier to maintain and to find them. >> >> Another question: why all existing primitive in VM have not a method in the image ? >> >> Cheers, >> --- >> Jannik Laval >> >> >> > >

Feb. 7, 2011

Re: [Pharo-project] Issue 3659 in pharo: Task bar appearance does not make sense

by pharo＠googlecode.com

Comment #2 on issue 3659 by ncalexan...(a)gmail.com: Task bar appearance does not make sense http://code.google.com/p/pharo/issues/detail?id=3659 In PharoInbox: SLICE-Issue-3659-Task-bar-appearance-does-not-make-sense-NickAlexander.2 I don't think this will be the final solution, but perhaps Tudor Girba can see what I've done and do it correctly. This looks fine with the stock themes, but I added two new color methods to UITheme to make it work, which is probably not desirable.

Feb. 7, 2011

[Pharo-project] new Cog VMs available

by Eliot Miranda

Hi All, new Cog VMs are available, SimpleStackBasedCogit @ http://www.mirandabanda.org/files/Cog/VM/VM.r2359/ and StackToRegisterMappingCogit @ http://www.mirandabanda.org/files/Cog/VM/VM.r2361. I think the new code generator is ready for prime time now. I fixed a number of bugs over the past three weeks and we're now using the StackToRegisterMappingCogit internally at Teleplace. There's still work to be done merging plugins and details with the standard VMs but I hope that r2361 is production-ready as far as core Smalltalk execution is concerned. Enjoy. Eliot

Feb. 7, 2011

Re: [Pharo-project] Hudson build for Seaside too?

by Dale Henrichs

On Feb 6, 2011, at 12:05 PM, Marcus Denker wrote: > > On Feb 4, 2011, at 4:13 PM, Dale Henrichs wrote: > >> Marcus, >> >> Since I seem to be on a symbolic version kick today, may I suggest that you use symbolic versions for Hudson: >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> package: 'ConfigurationOfSeaside30'; >> load. >> >> ((Smalltalk at: #ConfigurationOfSeaside30) project version: #stable) load. >> >> when you get a chance ... > > Done. > >> the above expression can be used for all of your Hudson builds regardless of pharo version. > > > use the same, but it loads then a different *stable* for each version? There _could_ be a different version for each platform, so by using #stable you'll always get the version that the developers expect to work. > > and > >> ((Smalltalk at: #ConfigurationOfSeaside30) project version: #unstable) load. > > > would load the latest code into e.g. 1.3? My opinion is that you should use the #stable symbolic version for Pharo1.3 as well. The rule should be: - the #stable version is the version that the developers recommend to use on a particular platform/platform version If no #stable version is defined, then the developers haven't finished their porting job yet. Just because the underlying platform version may be unstable doesn't mean that all of the configurations targeting Pharo1.3 should define another symbolic version for that means "use me on Pharo1.3" ... Anyone using an unstable platform must be aware that at any point in time there may be a change to the underlying system that may break other software in weird and wonderful ways, so the #stable symbolic version for an unstable version means that the version is the best that the developer has for that version....stable is the moral equivalent of latest version .... With that in mind, I think that you should modify the script to the following: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfSeaside30'; load. [ ((Smalltalk at: #ConfigurationOfSeaside30) project version: #stable) load. ] on: (Smalltalk at: #MetacelloVersionDoesNotExistError) do: [:ex | Transcript show: 'load skipped because no #stable version available']. Then if I know (for example) that Seaside3.0 doesn't work on Pharo1.3, I can specify that there is no #stable version for 1.3 and you won't even try to load the code let alone run the tests and have a bunch of failures... of course it also is a clear indication to other folks wondering if Seaside3.0 works on Pharo1.3 that it's not ready yet ... So to repeat, if there is a #stable version defined for Pharo1.3, then it is expected to work modulo any recent changes to the pharo core ... no #stable version defined means that the developers don't have a version ready to run yet. Dale

Feb. 7, 2011