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

[Pharo-project] Squeak VM Opt[31852:903] Can't open input server /Library/InputManagers/Inquisitor

by StÃ©phane Ducasse

Hi john When I'm doing /Applications/Squeak/Squeak\ 4.2.2beta1U.app/Contents/MacOS/Squeak\ VM\ Opt coral.image I get 2009-12-30 22:38:01.629 Squeak VM Opt[31852:903] Can't open input server /Library/InputManagers/Inquisitor Also this is strange but I have the impression that the image starts seems slower (of course I have around or more 20 app open). Stef

Dec. 30, 2009

Re: [Pharo-project] Pharo-beginner mailing list ? (St?phane Ducasse)

by Adrian Lienhard

Yes, lets start with a beginners list. We can also create a users list if needed at a later point. Adrian On Dec 30, 2009, at 19:08 , StÃ©phane Ducasse wrote: >> +1 >> >> Please start a beginner mailing list because Pharo is also some >> people's first look at smalltalk. A place to ask a mixture of >> question >> that come from being new to both would be welcome. > > I wrote the first version of the description about this one for > squeak and I like the spirit > A friendly place to get answers to even the most basic questions > about Squeak. <beginners(a)lists.squeakfoundation.org> > > 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] Developer guide ... ?

by John Toohey

On Wed, Dec 30, 2009 at 15:15, Guido Stepken <gstepken(a)googlemail.com>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 ... > > Have you looked at Traits? http://stephane.ducasse.free.fr/Presentations/2009-TraitsAtSC.pdf and much more on Google. > > 6. Databases: Magma seems to be fine as database, but also dog slow. I > really hesitate to start serious projects with Magma. > > Take a look at GlorpDBX, http://n2.nabble.com/ANN-SqueakDBX-Glorp-and-GlorpDBX-loads-easily-in-Pharo…. This give you support for many RDBMs including Postgres and Oracle. > 7. Speed, Memory consumption, Quality of modern algorithms: When working > > regards, Guido Stepken > -- > View this message in context: > http://n2.nabble.com/Developer-guide-tp4233838p4233838.html > 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 -- -JT

Dec. 30, 2009

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

by HernÃ¡n Morales Durand

2009/12/30 Guido Stepken <gstepken(a)googlemail.com>: > > Hi folks! > > I really would appreciate some sort of "orientation" in this jungle of code > in Pharo/Squeak ... > > 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? I have that information in my personal Swiki, too many pages to share and didn't see a potential profit since I have to search for work in .Net/Java now :( > > 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 ... > > 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? > > 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. Have you tried? http://wiki.squeak.org/squeak/2978 > > 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. > Then start one like we did in CONICET in Argentina, see http://documentosyobjetos.ning.com/video/opus-series-impresas-y-en (that's a video of the first FRBRoo implementation in Smalltalk, using Seaside and 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, > 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? Where > e.g. is 'fulltext hash' or 'fulltext search' implemented in Magma, e.t.c.? > Whole world works with fulltext databases (Google, MySQL, PostgreSQL, even > MSSQL, Oracle). Thats 'state of the art'!!!!!!!! Search in TB databases in > milliseconds! No, latest text searching algorithms aren't in that book. And the world doesn't starts and end in Google and Oracle databases, there are lot of users doing controlled vocabulary searches in commercial or government systems. Cheers, HernÃ¡n > > so far my 0.0199999999â¬ > > Keep up the good work on Pharo, it's still a long way to go! > > regards, Guido Stepken > -- > View this message in context: http://n2.nabble.com/Developer-guide-tp4233838p4233838.html > 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. 30, 2009

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

by StÃ©phane Ducasse

have a look at squeak -beginners people just ask questions and other reply. it is low profile from an architecture point of view. On Dec 30, 2009, at 8:42 PM, csrabak(a)bol.com.br wrote: > I _think_ it is a lot of hours of work. Once the mailing list starts, we'll to monitor it. With some periodicity we should assemble a FAQ, also because the proper nature of the list it is possible incorrect advice be posted by other members and we need to monitor and suggest the correct content as well. > > Thinking in retrospect I believe this should be launched when we have Pharo 1.0 released and we can stabilize documentation, procedures, etc. > > my 0.019999... > > -- > Cesar Rabak > > > > Em 30/12/2009 14:16, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: > > > +1 I would create it. It is not more than 1 hour or so of work. We don't loose nothing. Only the time will say if this was a good idea or not :) > > > > On Wed, Dec 30, 2009 at 5:07 PM, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > > +1 > > Its ok to separate the development of pharo from the > use/promotion/welcome to Pharo. > > Just don't let this become a mess with dozens of lists with a couple > of posts each. This won't > help Pharo cohesion in the long term. > > Miguel CobÃ¡ > > > > On Wed, Dec 30, 2009 at 5:41 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> 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 >> > > _______________________________________________ > 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] 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 StÃ©phane Ducasse

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

Dec. 30, 2009

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

by Lukas Renggli

> 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? http://www.seaside.st/community/conventions (Portability) > 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 ... Don't know what you are talking about? > 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? No. > 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 > 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

Dec. 30, 2009

[Pharo-project] Developer guide ... ?

by Guido Stepken

Hi folks! I really would appreciate some sort of "orientation" in this jungle of code in Pharo/Squeak ... 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? 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 ... 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? 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. 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. 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, 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? Where e.g. is 'fulltext hash' or 'fulltext search' implemented in Magma, e.t.c.? Whole world works with fulltext databases (Google, MySQL, PostgreSQL, even MSSQL, Oracle). Thats 'state of the art'!!!!!!!! Search in TB databases in milliseconds! so far my 0.0199999999â¬ Keep up the good work on Pharo, it's still a long way to go! regards, Guido Stepken -- View this message in context: http://n2.nabble.com/Developer-guide-tp4233838p4233838.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

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 Schwab,Wilhelm K

In addition to providing a nice service of building the images, Damien is really just the messenger. We can either have the latest and greatest of whatever various parties produce, or we can have an acceptance process and/or our own forks of packages that are known to be stable. Even with controls in place, we probably should have some type of testing period. One relatively easy way to accomplish that would be to show both the most recent dev and web builds and "last month's" versions on the download page. Anything we can do to prevent recurring bugs (the class/method node tests, anything that brings automated builds to a halt, etc.) will make it easier on people to test the latest images. Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Wednesday, December 30, 2009 1:30 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: 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 Thanks Lukas to be agree. I like your scripts, but the problem is that you use your own forked repository to get an stable version. I would love to have THAT, but in the original repositories. Examples: omnibrowser, unsorted, etc. Do you know how we can fix this ? On Wed, Dec 30, 2009 at 7:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>> wrote: Yes lukas now damien was nice to build the images because I could not do them. But damien is doing Java daily. Of course this is not Damien fault. Everybody here do as much as possible. And you do not like the package browser and we need it :). So I do not know what to do. - first we should add simple trait creation to the OB - now frankly I do not know how we could manage moose without the package browser. Yes, most of the problems in a dev image are related usually with the system browser :( Stef On Dec 30, 2009, at 7:16 PM, Lukas Renggli wrote: >> 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. > > This is what I am telling for years already. I don't know how other > people think about this, but to me it feels very embarrassing to have > to advertise my own way of building images over and over again? > > Here is it again: I am using the scripts > <http://code.google.com/p/pharo/wiki/ImageBuildScripts> to get from a > Pharo 1.0rc1 a fast and stable development and deployment image. The > image loads a well tested and fast OB, a working and well tested > refactoring engine, working syntax highlighting, working code > completion, and several other tools I use daily and that I cannot work > without. I am not telling it is bug free, but with my personal > workflow I can use it without getting interrupted by bugs all the > time. And when I encounter a bug, I fix it. > > I don't think that somebody can build a stable distribution without > using it 12 hours daily. Have a look at PharoCore, it is only rock > solid because Stef is using it all day long to integrate fixes. Have a > look at Squeak Trunk, it only sees improvement because Andreas is > using it all day long. Have a look at Debian, Gentoo, ... > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@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<mailto:Pharo-project@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 StÃ©phane Ducasse

Marcus Don't bame yourself. You did a good job and of course we could have stop earth to turn on itself but got no time for that :) Now the cool news is that there is the cool CompiledMethodTrailer in pharo1.1 and the changes of david lewis that are waiting for you :).... Rest from your Ikea unfolding and building furnitures :) I should rest from projects writing but I have one to write.... and I want it. Stef > > 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 > > > _______________________________________________ > 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