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

[Pharo-project] I still don't understand how this work

by Mariano Martinez Peck

I took a clean pharo1.0-10502-rc1dev09.12.2. I open Monticello Browser, and of course, there is no dirty (modified) package. I select the package OB-Standard, then select the repo http://source.wiresong.ca/ob , and click on changes 1) First, I would expect to have no changes with an Image I have just downloaded, without doing nothing and even when Monticello Browser showed me there is no dirty package. But.....this showed me several changes!!!

Dec. 30, 2009

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

by Schwab,Wilhelm K

Levente, I have to call you out on something: SSL is **definitely** not crap, and we should have a clean interface to it, probably via OpenSSL. I will eventually create same if not beaten to it. CORBA is also not crap. To be blunt, none of the listed technologies are crap if one has an externally defined problem (aka something that pay$ the bill$) that requires communicating with something that uses them. I will grant you that most of them have a pretty high crap coefficient, and I would not go out of my way to use them unless "forced" to do so. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Wednesday, December 30, 2009 5:45 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Developer guide ... ? On Wed, 30 Dec 2009, Guido Stepken wrote: [snip] As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: - http://www.google.com/search?q=squeak+threads (I guess a chapter on processes would be useful in PBE/SBE.) > 5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... > Without having a precise idea, where to find working examples to > exchance data with other systems, i would hesitate to begin to do projects with Pharo/Squeak... Some of this crap is available at squeaksource/squeakmap. Levente

Dec. 30, 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

The main problem is that we are not integrating enough. Please, take 5 minutes and see this example: Open http://source.wiresong.ca/ob In pharo1.0-10502-rc1dev09.12.2 the version loaded is OB-Standard-DamienCassou.438 which actually loads the OB-Standard-lr.434. I really don't understand why this. Is this a hack to our script to build dev images ??? Why we need to push up again a version ? Moreover, what happened with OB-Standard-DavidRoethlisberger.437 ? I was not integratd (if I understood correctly). So, the issue 1373 may be alive again. And what about the fix of OB-Standard-DavidRoethlisberger.434 ? and OB-Standard-dr.433 432 431 430 ... what happens with all those commits ? They don't seem to be merged. Is there a reason for this ? I am reading ok the commits ? Thanks Mariano On Wed, Dec 30, 2009 at 9:34 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Bart in Morphic may be this is not broken in 3.9 > there was a recordMorph that recorded the mouse location and that could be > replied after. > I read the code long time ago and forgot but may. > > I remember that on VisualAge there was a tool to capture and replay UI > tests. > So I would be really interested to see how far you can go with your idea. > > On Dec 30, 2009, at 8:50 PM, Bart Gauquie wrote: > > > I highly agree also !! > > > > Its related to Pharo for Professional Development thread I started 2 > weeks ago. It basically says the same. > > My gut feeling is still that stability should be the number one focus. > Its great to innovate, but innovation must not harm stability. > > > > For me stability is keeping regression bugs to a minimum. To test the > stability of the GUI/Morphic parts of Pharo, I started to create a little > project: http://www.squeaksource.com/MorphicsRecordNPlay/. This can record > mouse events and replay them afterwards. My idea was to take this as a sort > of automated integration testing of Pharo. You can then record all kinds of > stuff: opening a browser, clicking on a class, try every option out, ... . > I've also attempted to automatically convert these recordings into sunit > test cases so they can be automatically replayed, but I stumbled upon > following limitation : Long method can not be compiled using #compile: > aString. Havent looked into it further yet. Any ideas here how these can be > replayed? > > > > Kind Regards, > > > > Bart > > > > > > 2009/12/30 Mariano Martinez Peck <marianopeck(a)gmail.com> > > 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 > > #allCategory->AllMethodCategory > > #categories->MethodCategory > > #dy...etc... > > navigation: an O2DefaultEdgeNavigation > > theClass: ShortIntegerArray > > > > O2MetaEdge>>nodesForParent: > > Receiver: #dynamicProtocols->DynamicProtocols > > Arguments and temporary variables: > > aNode: OBClassNode<ShortIntegerArray> > > Receiver's instance variables: > > label: 'dynamicProtocols' > > selector: #dynamicProtocols > > metaNode: DynamicProtocols > > #methods->Method > > > > navigation: an O2DefaultEdgeNavigation > > isDropEdge: nil > > > > ... > > -- > > View this message in context: > http://n2.nabble.com/Issue-1721-Refactoring-appears-to-be-broken-in-web-dev… > > 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 > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > imagination is more important than knowledge - Albert Einstein > > Logic will get you from A to B. Imagination will take you everywhere - > Albert Einstein > > Learn from yesterday, live for today, hope for tomorrow. The important > thing is not to stop questioning. - Albert Einstein > > The true sign of intelligence is not knowledge but imagination. - Albert > Einstein > > However beautiful the strategy, you should occasionally look at the > results. - Sir Winston Churchill > > It's not enough that we do our best; sometimes we have to do what's > required. - Sir Winston Churchill > > _______________________________________________ > > 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. 30, 2009

Re: [Pharo-project] Pharo-beginner mailing list ?

by Norbert Hartl

I would strongly opt against a pharo beginners list. I think the squeak beginners list is the right place to be. To fork off the code from squeak was a good idea. But it is also troublesome as we experienced already. Forking off everything or just doubling everything won't bring any benefit. A beginner won't differ between squeak and pharo. A beginner stumples with this particular environment regardless if it is squeak or pharo. So please let us just try to join forces. Norbert On 30.12.2009, at 12:41, StÃ©phane Ducasse wrote: > Hi all > > I remember that the squeak-beginner mailing-list (our ideas) was a huge success > since it enabled people to ask questions and have less mails. > So a question to you: do you think that it would be good to have a pharo-beginner mailing list? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2009

Re: [Pharo-project] Fwd: 2GB changes file and a pony (was: [squeak-dev] ALL CLEAR (Re: CompiledMethodTrailers ready for use))

by David T. Lewis

On Wed, Dec 30, 2009 at 08:49:23PM +0100, Marcus Denker wrote: > > On Dec 28, 2009, at 11:27 AM, St?phane Ducasse wrote: > > > Yes :) > > > > Marcus would like to have code inside the image... since a couple of years :) > > yes... Klaus Witzel worked on this some years ago (I think even after I told him that > this would be high on my list... Klaus used to live in Bern and visited the Squeak meeting > there regularly.) > > This did not make it into 3.9... we ran a bit out of steam at the end :-) > > Maybe I should explain that I did 3.9 in parallel to my PhD work. Unpayed, with no hidden > side agenda other than the realization that one can't invent the future if one can not even fix a typo in a comment. > > I think one could critisize that I just integrated other peoples fixes... but that had multiple reasons: > > 1) Focus was on the PhD.... and doing all these boring things that are a lot of work that one needs to do to have a future > in Research. > > 2) Of what use is it to do some cool enancement for Squeak if chances of integration are zero? I never understood > the brave people who did sent patch after patch with almost nothing ending up in the system. > > 3) Integrating is far less trivial than people might think. > > Integrating is especially difficult in a system "with a history" like Squeak. But in the end, I think we did a good job with 3.9. > Regardless of what people said afterwards... I guess now everyone agrees, after all those evil things we did that people crucified > us for turned out to be not that bad after all. Marcus, Absolutely yes, on both counts. System integration really is hard work, and it is much more difficult and time consuming that it appears to be. Also you produced a good job with 3.9, with lots of progress that forms the basis of Pharo and Squeak trunk today. So thank you! It is an interesting challenge to do work like this using tools like a mailing list and bug trackers. It is very easy for negative ideas to be echoed endlessly, to the point where they seem to have their own credibility. The positive comments are less common and nobody ever wants to argue about them, so the echoes fade away quickly. Dave

Dec. 30, 2009

Re: [Pharo-project] [squeak-dev] Re: Some questions about new traits (Crismas edition) ; )

by David T. Lewis

On Wed, Dec 30, 2009 at 09:50:40AM +0100, St?phane Ducasse wrote: > > > >> - The requires algorithm is not directly related to Traits (as I > >> pointed out in a recent mail) > > > > That's cool, but why is it there? > > I can reply to you on that one :) <snip> > I imagine that this gives an historical view to the question and I thanks > you because we will probably clean it. Stef, Thanks for providing this historical background. It's an interesting story and helps understanding for those of us who did not have an office near by :) Dave

Dec. 30, 2009

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

by Levente Uzonyi

On Wed, 30 Dec 2009, Guido Stepken wrote: > > > 1. What classes are compatible to other smalltalks? When i follow > mailing-lists of Dolphin, Squeak, VW, VA Magma - there still is a bunch of > porting problems. Why?????? What classes should i give preference to > minimize porting cost? Why would you like to port your app? > 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 ... Reading a book is generally helpful when someone is learning a new language. But it's not necessary with smalltalks since the system is so open that, one can learn by exploring it. > 4. Multitasking, green threads, ... There are really missing some pointers, > howto code e.g. a background process that is fetching some data from e.g. > MySQL or reading/writing large files, sending data over network - without > freezing the GUI. As others pointed out, these are implemented with blocks. What would you do if, say you wanted to know how to do threading in java? Reading a book or googling is helpful: - http://www.google.com/search?q=squeak+threads (I guess a chapter on processes would be useful in PBE/SBE.) > 5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... Without > having a precise idea, where to find working examples to exchance data with > other systems, i would hesitate to begin to do projects with Pharo/Squeak... Some of this crap is available at squeaksource/squeakmap. > 6. Databases: Magma seems to be fine as database, but also dog slow. I > really hesitate to start serious projects with Magma. > > 7. Speed, Memory consumption, Quality of modern algorithms: When working > with Seaside, PIER ... that stuff is dog slow, memory consuption is hardly > predictable. That makes webhosting e.g. on vservers absolutely impossible, > the whole system quickly becomes unstable. IMHO in Pharo there are routines, 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). > that really waste a lot of memory, that could be programmed in a more > intelligent way, expecially collection's algorithms ... ;-) > Perhaps Donald Knuth books ("Art of Computer Programming") could help? Can you point out a few examples? > Where e.g. is 'fulltext hash' or 'fulltext search' implemented in Magma, e.t.c.? What does Magma have to do with Pharo in this context? Where did you read that Magma has full text search? (Btw if you have a data structure that has full text search capabilities then voila, Magma has full text search.) > Whole world works with fulltext databases (Google, MySQL, PostgreSQL, even > MSSQL, Oracle). Thats 'state of the art'!!!!!!!! Search in TB databases > in milliseconds! If you need an RDBMS then use one, there are several drivers available. Levente > > so far my 0.0199999999ËË > >Keep up the good work on Pharo, it's still a long way to go! > >regards, Guido Stepken >--

Dec. 30, 2009

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

by Mariano Martinez Peck

On Wed, Dec 30, 2009 at 11:24 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi Mariano, > > 2009/12/30 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > >> > >> > 4. Multitasking, green threads, ... There are really missing some > >> > pointers, > >> > howto code e.g. a background process that is fetching some data from > >> > e.g. > >> > MySQL or reading/writing large files, sending data over network - > >> > without > >> > freezing the GUI. > >> > >> [ self writeLargeFile ] fork > > > > > > This is not actually true if the database driver has to use FFI to > > communicate to an external librarym since FFI locks the complete VM while > a > > function is being executed. So, in certain percentage, he is right. > > > > I think sometimes this depends of the library itself, for example in > the ZOOM API for the Z39.50 protocol you may specify an async > parameter in the connection mode for operating asynchronously, then > you would have non-blocking calls with the exception of event polling. > Yes, true, that's exactly what we are doing in SqueakDBX, but it depends not only on OpenDBX but in the database client library :( Anyway...I would like not to block the whole VM never :) > Cheers, > > HernÃ¡n > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 30, 2009

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

by HernÃ¡n Morales Durand

Hi Mariano, 2009/12/30 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> > 4. Multitasking, green threads, ... There are really missing some >> > pointers, >> > howto code e.g. a background process that is fetching some data from >> > e.g. >> > MySQL or reading/writing large files, sending data over network - >> > Â without >> > freezing the GUI. >> >> [ self writeLargeFile ] fork > > > This is not actually true if the database driver has to use FFI to > communicate to an external librarym since FFI locks the complete VM while a > function is being executed. So, in certain percentage, he is right. > I think sometimes this depends of the library itself, for example in the ZOOM API for the Z39.50 protocol you may specify an async parameter in the connection mode for operating asynchronously, then you would have non-blocking calls with the exception of event polling. Cheers, HernÃ¡n

Dec. 30, 2009

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

by Mariano Martinez Peck

> > > 4. Multitasking, green threads, ... There are really missing some > pointers, > > howto code e.g. a background process that is fetching some data from e.g. > > MySQL or reading/writing large files, sending data over network - > without > > freezing the GUI. > > [ self writeLargeFile ] fork > This is not actually true if the database driver has to use FFI to communicate to an external librarym since FFI locks the complete VM while a function is being executed. So, in certain percentage, he is right. > > > 5. Standards: XML-RPC, SOAP, RMI, CORBA, .... encryption (SSL) ... > Without > > having a precise idea, where to find working examples to exchance data > with > > other systems, i would hesitate to begin to do projects with Pharo/Squeak > > ... > > > > 6. Databases: Magma seems to be fine as database, but also dog slow. I > > really hesitate to start serious projects with Magma. > > GemStone/S > > > 7. Speed, Memory consumption, Quality of modern algorithms: When working > > with Seaside, PIER ... that stuff is dog slow > > Compared to what? > > > That makes webhosting e.g. on vservers absolutely impossible, > > the whole system quickly becomes unstable. IMHO in Pharo there are > routines, > > that really waste a lot of memory, that could be programmed in a more > > intelligent way, expecially collection's algorithms ... ;-) > > There is a submission process for improvements. Feel free to contribute. > > Lukas > > -- > 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. 30, 2009