- Pharo-dev - lists.pharo.org

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

[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