- Pharo-dev - lists.pharo.org

[Pharo-project] Pharo testers.... WE NEED YOU!!!

by Mariano Martinez Peck

Ok, you already know the idea. Damien, or the person that build the next Pharo dev and web images will send those Pharo beta testers a private email with the link to download the image. No ANN and now update is done yet to the website. Then the betatesters use that image as much as possible for a couple of days. Report bugs if necessary and if it is ok, the image is released. Regarding the list of beta testers would be perfect if we cover the combination of OS (Linux, Mac, Windows) and the browser (OB, O2). But we cannot pretend too much. Take into account that not all the people can work with a new image very easily because they have to migrate data ...etc..Others can just download the project from MC and start to work :) So...here is the list, if you offer yourself, it would be cool to know: OS, VM version, Dev or Web, browser you usually work, 32 o 64 bits, I will then collect this and I will put it in the wiki. - Mariano Martinez Peck. Mac OS, Squeak 4.2.2beta1U.app, Dev, OB, 32 bits - Stan Shepherd WHO ELSE IS IN THE LIST ?? cheers and happy new year!!

Dec. 31, 2009

Re: [Pharo-project] We need to do something, seriously!!!! [WAS] Fwd: Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols

by Mariano Martinez Peck

On Thu, Dec 31, 2009 at 11:32 AM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > > Mariano Martinez Peck wrote: > > > > Hi folks. I am really concerned about the instability of the dev and web > > images. WE CANNOT RELEASE a RC where you cannot even double click in a > > class. This cannot happens. We all know that all software can have bugs. > > But > > again, we cannot release images, and even RC images, which are supposed > to > > be quite stable, where you cannot right click a class, you cannot > > refactor, > > you cannot even right click in the code pane. And don't told me "I use > the > > keyboard" because I don't care what you do. A lot of people use the > mouse. > > > > I have already said it several times. Most of the people don't care how > > nice, fast, clean, open source and well programmed is the Pharo Core > image > > if they cannot use the Dev or Web image. > > > > Remember that our users are external users, you even don't care about the > > core. They just use Pharo, they are not developers. > > > > I really think we need to fix this. You are giving a bad impression of > > something which is not true. You are doing AN EXCELLENT work with > > PharoCore. > > Why to wast all of this for this kind of situations? It is a pity :( > > > > I don't know the best solution for this. I will only give an idea I have, > > but I would really like to hear you ideas and do something with this. > > > > 1) We are building a dev image per month more or lest. 5 days before en > of > > months (more or less), the dev image should be built. > > > > 2) During 5 years, some people will use that image as a beta tester. I > > would > > ideally to have different users: different OS, different browsers, etc. > > This people will use that image for their work for those 5 days and > report > > any bug that appears. Of course, not all people can do that. > > How is volunteer to be beta tester ? We can create a wiki page for that > > if > > you are agree with the idea. > > > > 3) After those 5 days, if the image is stable enough, it is released. If > > it > > is not, it is just not released. Nobody will kill you if one month you > > don't > > release a new image. In addition, is better not to release an unstable > > image > > that releasing it and not be able to do a single right click. > > > > In Canonical, all the employees MUST to use for one month or more each > > Ubuntu release. We are not employee, but we can do something similar. > > > > What do you think ? > > > > Cheers > > > > Mariano > > > > > > ---------- Forwarded message ---------- > > From: Stan Shepherd <stan.shepherd414(a)gmail.com> > > Date: Wed, Dec 30, 2009 at 6:26 PM > > Subject: [Pharo-project] Issue 1721: Refactoring appears to be broken in > > web > > dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols > > To: pharo-project(a)lists.gforge.inria.fr > > > > > > > > NB this logs a particular walkback, but the whole area appears to be > > unworkable in the web dev image. Please could the maintainers click, > right > > click, middle click on each part of refactoring browser, take each menu > > item, etc. This will be much quicker than logging one bug at a time. > > If this turns out to be the last one, my apologies in advance. > > Thanks. ...Stan > > > > > > VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: > > #10074] > > Image: PharoCore1.0rc1 [Latest update: #10502] > > pharo1.0-10502-rc1web09.12.2 > > > > Class browser used (if applicable): OR2PackageBrowser. > > > > OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols > > Receiver: OBClassNode<ShortIntegerArray> > > Arguments and temporary variables: > > aMessage: dynamicProtocols > > exception: MessageNotUnderstood: > > OBClassNode>>dynamicProtocols > > resumeValue: nil > > Receiver's instance variables: > > metaNode: Class > > > > > Mariano Martinez Peck wrote: > > > > ... volunteer to be beta tester ? > > > > I volunteer. And being on Linux and a mouse user, I seem to hit a lot of > the > wrinkles. > > Ok, perfect. I will open another thread for this then. > > Mariano Martinez Peck wrote: > > > > I don't know the best solution for this > > > > Mariano, Adrian's fix does indeed seem to fix up this whole area. After > running it, I can get right through the menus to run code critics, and > right/left/middle clicks don't cause problem. It would seem the image on > the > download page should be replaced ASAP with one which has had this > operation. > > Yes, I am agree. Can someone do this please? I have no idea how to do it neither I have the rights. I just to pick up the latest dev and web image from the website evaluate Gofer it wiresong: 'ob'; package: 'OB-Refactory'; revert save it and upload it again. In addition, we have to take a decision here: 1) Remove O2 from the script until O2 has NO dependencies and overrides in OB and until O2 loads perfectly in a core image without anything about OB. Those who want to use it anyway, can install by their self. 2) Add this piece of hack to our script. Opinions ? > > Adrian Kuhn wrote: > > > > Gofer it > > wiresong: 'ob'; > > package: 'OB-Refactory'; > > revert > > > > this will revert all conflicting package extensions of O2 back to those > of > > OB > > so that you can work with both the green and the yellow browser of OB. > > > > Mariano, thanks for bringing this into sharp focus. As Bart identified, > it's > been a real concern that our "shop window" has been broken like this. > > You are welcome. I don't pretend Pharo to be rock solid. But I pretend not to have those errors were you cannot even browse a class or right click on the code. Cheers Mariano > ...Stan > > -- > View this message in context: > http://n2.nabble.com/We-need-to-do-something-seriously-WAS-Fwd-Issue-1721-R… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 31, 2009

Re: [Pharo-project] Developer guide ... ?

by Geert Claes

Guido Stepken wrote: > > 2. Interfaces ... hmmm, well ... there are many programmes thinking in > categories of "interfaces", "libraries", "class dependencies", e.t.c. Of > course, Smalltalk is something completely different, but it makes it > difficult for s.b. e.g. coming from Java or C++, to find into Smalltalk > concepts. Gofer - till now, i have just a wage imagination, what it's good > for ... > I have to agree that the whole, project, component, categories, packages, versioning, monticello, metacello thing is still a bit complicated, however I do believe the Pharo team is working hard on this and I think it will get straightened out a bit soon. Guido Stepken wrote: > > 3. GUI builder. IMHO, it's very easy to build a GUI with morphic. In > Squeak, e.g. i simply generate my input forms with EToys, which can be > replaced of course by a few lines of code typed in by hand ... But for > developers coming from Java, C++ ... the first ask for a GUI builder and > XAML e.t.c. There should be some documentation, that leads programmers, > that are willing to switch over to Smalltalk, into the right direction. > Just a few examples, e.g. how to build a form, that scrolls through some > MySQL data sets, really would help. What about compatibility? Is Morphic > portable to other Smalltalks? > Assuming you are considering web apps too I would have a look at seaside (which has been ported to a number of smalltalk dialects) or AIDAWeb. From what I understand so far seaside (AIDAWeb will have something similar) has a nice concept of canvas and brushes. It does still lack some sort of nice 4GL GUI WYSIWYG painter .... but I guess you can build one yourself :) Guido Stepken wrote: > > 6. Databases: Magma seems to be fine as database, but also dog slow. I > really hesitate to start serious projects with Magma. > I believe there is more than just Magma though ... how about GOODS, SqueakDBX project, SandstoneDB, GemStone's GLASS ... For a serious (if that refers to big?) project I think you ought to look at GemStone. Guido Stepken wrote: > > Keep up the good work on Pharo, it's still a long way to go! > I agree the Pharo team has come a long way in a fairly short time! Go Pharo :) -- View this message in context: http://n2.nabble.com/Developer-guide-tp4233838p4235891.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 31, 2009

[Pharo-project] where can I see the slices that were removed from inbox?

by Mariano Martinez Peck

I need to load a slice in 1.0 which was integrated in 1.1 and removed from PharoInbox. Where can I find it? thanks mariano

Dec. 31, 2009

Re: [Pharo-project] Can't debug in 1.1

by Marcus Denker

On Dec 31, 2009, at 9:50 AM, StÃ©phane Ducasse wrote: > Probably the changes of Martin von Lowis. Yes. The changeset had code to migrate all instances... it might be that the debugger's use of WeakKeyDictionary was added by Eliot? This would explain why it was not migrated. I suggest to just do the reset in a postscript in one of the next updates, and it's fixed. > I imagine that when marcus is bad from holidays he can tell us more. > I'm back... kind of. Decided not to travel to south germany this morning after moving boxes for 3 days... better to have an IKEA-unboxing-relaxing-reading-emails-hacking-weekend. Marcus > Now I try to reproduce it in 11128. > > I put a self halt in a method and execute the method. > And I got no problem. > After I tried to select 'self halt' + doit in the debugger itself and it worked too. > > Did you have a way reproduce it systematically ? > > Stef > On Dec 31, 2009, at 4:17 AM, Martin McClure wrote: > >> This one's pretty nasty. >> >> Symptom: >> >> The debugger in recent and current 1.1 images is completely broken. >> >> To reproduce (save your image first!): >> >> "self halt" doit. It goes into an infinite loop, and if there's a way to >> get out of that without killing the VM I'd like to know about it. Alt-. >> works, but just tries to open another debugger, which goes into another >> infinite loop, etc. >> >> >> >> Cause: >> >> DebuggerMethodMap>MapCache is a WeakIdentityKeyDictionary, but it is >> corrupt. It has an array of 22 nils, expired is 0, so it contains >> nothing, but tally=16. >> >> This causes MapCache to lie about its size. >> >> This drives DebuggerMethodMap class>>cacheDebugMap:forMethod: into an >> infinite loop, the whileTrue: condition is always true, it keeps trying >> to remove non-existent elements to get the size to be less than 16 but >> the size is always 16. >> >> I don't see any obvious code paths to get into this state. I suspect it >> may have been left in this state when weak collections were updated with >> the new code not too long ago. >> >> >> Cure: >> >> In an inspector, set tally=0. Debuggers then work again. >> >> Not sure how to package this as a slice, so I'll leave the update to >> someone else, and get back to hashing, which was hard when every >> walkback froze my system :-) >> >> >> Regards, >> >> -Martin >> >> _______________________________________________ >> 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

Dec. 31, 2009

Re: [Pharo-project] We need to do something, seriously!!!! [WAS] Fwd: Issue 1721: Refactoring appears to be broken in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols

by Stan Shepherd

Mariano Martinez Peck wrote: > > Hi folks. I am really concerned about the instability of the dev and web > images. WE CANNOT RELEASE a RC where you cannot even double click in a > class. This cannot happens. We all know that all software can have bugs. > But > again, we cannot release images, and even RC images, which are supposed to > be quite stable, where you cannot right click a class, you cannot > refactor, > you cannot even right click in the code pane. And don't told me "I use the > keyboard" because I don't care what you do. A lot of people use the mouse. > > I have already said it several times. Most of the people don't care how > nice, fast, clean, open source and well programmed is the Pharo Core image > if they cannot use the Dev or Web image. > > Remember that our users are external users, you even don't care about the > core. They just use Pharo, they are not developers. > > I really think we need to fix this. You are giving a bad impression of > something which is not true. You are doing AN EXCELLENT work with > PharoCore. > Why to wast all of this for this kind of situations? It is a pity :( > > I don't know the best solution for this. I will only give an idea I have, > but I would really like to hear you ideas and do something with this. > > 1) We are building a dev image per month more or lest. 5 days before en of > months (more or less), the dev image should be built. > > 2) During 5 years, some people will use that image as a beta tester. I > would > ideally to have different users: different OS, different browsers, etc. > This people will use that image for their work for those 5 days and report > any bug that appears. Of course, not all people can do that. > How is volunteer to be beta tester ? We can create a wiki page for that > if > you are agree with the idea. > > 3) After those 5 days, if the image is stable enough, it is released. If > it > is not, it is just not released. Nobody will kill you if one month you > don't > release a new image. In addition, is better not to release an unstable > image > that releasing it and not be able to do a single right click. > > In Canonical, all the employees MUST to use for one month or more each > Ubuntu release. We are not employee, but we can do something similar. > > What do you think ? > > Cheers > > Mariano > > > ---------- Forwarded message ---------- > From: Stan Shepherd <stan.shepherd414(a)gmail.com> > Date: Wed, Dec 30, 2009 at 6:26 PM > Subject: [Pharo-project] Issue 1721: Refactoring appears to be broken in > web > dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols > To: pharo-project(a)lists.gforge.inria.fr > > > > NB this logs a particular walkback, but the whole area appears to be > unworkable in the web dev image. Please could the maintainers click, right > click, middle click on each part of refactoring browser, take each menu > item, etc. This will be much quicker than logging one bug at a time. > If this turns out to be the last one, my apologies in advance. > Thanks. ...Stan > > > VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: > #10074] > Image: PharoCore1.0rc1 [Latest update: #10502] > pharo1.0-10502-rc1web09.12.2 > > Class browser used (if applicable): OR2PackageBrowser. > > OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols > Receiver: OBClassNode<ShortIntegerArray> > Arguments and temporary variables: > aMessage: dynamicProtocols > exception: MessageNotUnderstood: > OBClassNode>>dynamicProtocols > resumeValue: nil > Receiver's instance variables: > metaNode: Class > Mariano Martinez Peck wrote: > > ... volunteer to be beta tester ? > I volunteer. And being on Linux and a mouse user, I seem to hit a lot of the wrinkles. Mariano Martinez Peck wrote: > > I don't know the best solution for this > Mariano, Adrian's fix does indeed seem to fix up this whole area. After running it, I can get right through the menus to run code critics, and right/left/middle clicks don't cause problem. It would seem the image on the download page should be replaced ASAP with one which has had this operation. Adrian Kuhn wrote: > > Gofer it > wiresong: 'ob'; > package: 'OB-Refactory'; > revert > > this will revert all conflicting package extensions of O2 back to those of > OB > so that you can work with both the green and the yellow browser of OB. > Mariano, thanks for bringing this into sharp focus. As Bart identified, it's been a real concern that our "shop window" has been broken like this. ...Stan -- View this message in context: http://n2.nabble.com/We-need-to-do-something-seriously-WAS-Fwd-Issue-1721-R… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 31, 2009

Re: [Pharo-project] Cannot even browse a class in web image

by Mariano Martinez Peck

On Thu, Dec 31, 2009 at 10:14 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > I've encountered and fixed that bug a long time ago in OB-Morphic in > OBLazyListMorph>>display:atRow:on:. This is the same bug in > O2-Morphic. Compare with "[Pharo-project] We need to do something, > seriously!!!! [WAS] Fwd: Issue 1721: Refactoring appears to be broken > in web dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: > #dynamicProtocols". > > OK, thanks Lukas! But you see that we have a serious problem? How many time you heard "I have already fix this in ....." or "This bug is present again" We really need to do something about our integrations. Thanks Mariano > Lukas > > 2009/12/31 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > Issue: http://code.google.com/p/pharo/issues/detail?id=1724 > > > > Pharo image: pharo1.0-10502-rc1web09.12.2 > > Pharo core version: 10502 > > Virtual machine used: Squeak 4.2.2beta1U.app > > Class browser used if applicable: O2PackageBrowserAdaptor. > > > > Steps to reproduce: > > 1. Open a class browser > > 2. Click on the class ByteArray from the package Collection-Arrayed > > > > 'MessageNotUnderstood: ByteSymbol>>hasWideCharacterFrom:to:' > > > > I attach PharoDebug.log > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > http://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 >

Dec. 31, 2009

Re: [Pharo-project] Developer guide ... ?

by StÃ©phane Ducasse

> > SSL is useful, though most of the time it's used for HTTPS, and we have > the cURL plugin to handle that. And you're right, the Cryptography team > doesn't exists anymore, the code was abandoned, but the Croquet guys > picked it up and fixed a few bugs in it, though it still has some. The > code is available here: > http://croquet-src-01.oit.duke.edu:8886/Contributions.html > (Note that without the DESPlugin the implementation is really > slooooooooooow) thanks for the pointer. May be we should package it again and make it available. Stef

Dec. 31, 2009

Re: [Pharo-project] Developer guide ... ?

by StÃ©phane Ducasse

John why not call do a call in the seaside mailing-list to see if we could gather some money for that? I think that this is a good to have functionality. Stef On Dec 31, 2009, at 2:49 AM, John M McIntosh wrote: > > On 2009-12-30, at 4:54 PM, Schwab,Wilhelm K wrote: > >> Levente, >> >> I'll give you a pass on RPC, on SOAP for sure, and _almost_ on CORBA :) However, a culture of dismissing important things as crap lead us to a point approaching 15 years into Squeak's existence where it does not have ready access to SSL. I know about stunnel, but that is more cheat than fix. Pharo needs to embrace the worthy or we will still be on the fringe 15 years from now, and that would be tragic. >> >> Bill > > Well someone needs to sit for a week(s) (an oversimplification?) and write the OpenSSL FFI interface. > > You have funding for that? > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 31, 2009

Re: [Pharo-project] Developer guide ... ?

by StÃ©phane Ducasse

Hi levente In VW there is the ObjectMemory class and its policy for doing that. Now what were your setup in Squeak. Passing argument to the vm as parameter or something more elaborated? On Dec 30, 2009, at 11:45 PM, Levente Uzonyi wrote: > Tuning the garbage collector (which one should do when deploying an image) may help here. Btw I didn't experience such problems with seaside (2.8 & 3.0). Stef

Dec. 31, 2009