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

Re: [Pharo-project] databases

by laurent laffont

Thank you very much Mariano. Now I can choose because Pharo is still a hobby for me ;) I've started learning Magma, it's fun, so easy .... Laurent Laffont 2010/2/18 Mariano Martinez Peck <marianopeck(a)gmail.com> > > Hi Laurent. > > I agree with you. From my point of view, there are a lot of persistence > strategies and possibilities. But the problem I faced most of the time is > that you are not able to choose. It is not common you can choose the > database and even more the database. At least in real business or company > applications. Thee are a LOT of reason, logical and not logical. If you want > I can share with you the reasons I found so far. > > If you can choose, I would probably use a OO database. Magma or GLASS are > the better solutions for me. There is also GOODS but I heard bad comments > from a friends that are using it at their work. > > Then you have all those "non traditional" databases like Toyko, CouchDB, > MongoDB, etc. You can give them a try. > > You have also serializers like SIXX, ImageSegments, SmartRefStream, save in > the image, etc. This can be a solution for very limited for my opinion > (small apps). However, they are very useful when starting a project or even > for prototyping. > > Finally, you may HAVE or you want to use relational database. First, which > database? most of the time, you cannot choose. For Pharo, there seems to be > native drivers for PostgreSQL and MySQL. The first one is working on Pharo. > The second one I don't know. SQLite driver I think it is not native (maybe I > am wrong...). We did SqueakDBX where you can talk with Oracle, MSSQL, MySQL, > PostgreSQL, Sqlite3, Firebird (only windows) and ODBC in all OS (Linux, Mac > Os and Windows). > > After the "driver layer" then you have Glorp and SqueakSave mostly. Glorp > is much powerful and complete. But, the Pharo/Squeak version is quite old as > Glorp is developed in VW. The "problem" with Glorp is that you have to write > all the queries by hand. If you want to use other that PostgreSQL with Glorp > in Pharo then you need to install GlorpDBX. You can SandstoneDB if you want > and then you also have Glorp-ActiveRecord, but only VW (as it is new, it is > not ported to squeak or pharo). In those approaches, the time of developing > is less as you don't have to write all the mappings. > Finally, with SqueakSave you can automatically persist. It takes care of > writing everything. You don't need to write the mappings. Of course, you > need to follow certain conventions in the names. SqueakSave supports MySQL > and PostgreSQL only althought they wanted to interface with SqueakDBX to > support all databases. I don't know neither if it works on Pharo. Of > course, it seems to be a less slower than Glorp as the queries are not the > faster. > > If I were you, for the screencast, I would really like to see the following > scenario: you have a domain model and then you persists: > > 1) Image based / serializers (sixx, ImageSegments, SmartRefStream, etc) > 2) OO database -> magma or GLASS > 3) Relational database -> Glorp, SqueakSave, etc > > Each item can be a different post and for each item you show the advantages > or disadvantages and of course, in each item, the domain model is the same. > Of course this may require a lot of time and effort :) > > Uffff now I realized this is almost the same Torsted said. Sorry. > > Cheers > > Mariano > > > > 2010/2/17 laurent laffont <laurent.laffont(a)gmail.com> > >> Hi, >> >> I would like to learn on Pharo + databases. I've seen there's several >> solutions in both object and relational databases. >> - Which (open source) object database should I start with (most used) ? >> - Which object database can be accessed from Smalltalk AND Ruby or Python >> ? How ? >> - I want to try MySQL too. >> Is there up to date small applications on squeaksource which show this >> stuff quite well ? >> >> Thanks for help ! >> >> Laurent Laffont >> >> _______________________________________________ >> 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 >

Feb. 18, 2010

Re: [Pharo-project] Keyboard events issue on Mac VM

by Pavel Krivanek

If you press the key "a", you`ll get #(2 2534082 0 1 0 0 0 1) #(2 2534082 97 0 0 97 0 1) #(2 2534157 0 2 0 0 0 1) from the virtual machine. For "A": #(2 2536225 0 1 1 0 0 1) #(2 2536225 65 0 1 65 0 1) #(2 2536413 0 2 8 0 0 1) The only event with the information about pressed character is keyStroke (the fourth value is 0) so you will not know the resultant character because MacRoman charCode and/or utf32Code is missing (they are present on Linux). It is printed from InputEventFetcher>>signalEvent:. Am I missing something? -- Pavel On Thu, Feb 18, 2010 at 9:46 PM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > You are mistaken in your interpretation of the event codes. > please read http://isqueak.org/ioGetNextEvent > > You will find the windows VM will return Windows meta key codes which won't match the values for keyStroke > > Tweak in Croquet & Sophie uses Â KeyDown/keyUp for Tweak event handling and ignores keyStroke: > > > On 2010-02-18, at 12:32 PM, Pavel Krivanek wrote: > >> Hi, >> >> The Mac OS virtual machine has wrong processing of keyUp and keyDown >> events. It discards event character value. >> >> This events are very rarely used (keyStroke is preferred) so there`s >> no surprise that it was not reported before. >> >> See http://code.google.com/p/pharo/issues/detail?id=1995 >> >> Cheers, >> -- Pavel >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > =========================================================================== > 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 >

Feb. 18, 2010

Re: [Pharo-project] databases

by Mariano Martinez Peck

Hi Laurent. I agree with you. From my point of view, there are a lot of persistence strategies and possibilities. But the problem I faced most of the time is that you are not able to choose. It is not common you can choose the database and even more the database. At least in real business or company applications. Thee are a LOT of reason, logical and not logical. If you want I can share with you the reasons I found so far. If you can choose, I would probably use a OO database. Magma or GLASS are the better solutions for me. There is also GOODS but I heard bad comments from a friends that are using it at their work. Then you have all those "non traditional" databases like Toyko, CouchDB, MongoDB, etc. You can give them a try. You have also serializers like SIXX, ImageSegments, SmartRefStream, save in the image, etc. This can be a solution for very limited for my opinion (small apps). However, they are very useful when starting a project or even for prototyping. Finally, you may HAVE or you want to use relational database. First, which database? most of the time, you cannot choose. For Pharo, there seems to be native drivers for PostgreSQL and MySQL. The first one is working on Pharo. The second one I don't know. SQLite driver I think it is not native (maybe I am wrong...). We did SqueakDBX where you can talk with Oracle, MSSQL, MySQL, PostgreSQL, Sqlite3, Firebird (only windows) and ODBC in all OS (Linux, Mac Os and Windows). After the "driver layer" then you have Glorp and SqueakSave mostly. Glorp is much powerful and complete. But, the Pharo/Squeak version is quite old as Glorp is developed in VW. The "problem" with Glorp is that you have to write all the queries by hand. If you want to use other that PostgreSQL with Glorp in Pharo then you need to install GlorpDBX. You can SandstoneDB if you want and then you also have Glorp-ActiveRecord, but only VW (as it is new, it is not ported to squeak or pharo). In those approaches, the time of developing is less as you don't have to write all the mappings. Finally, with SqueakSave you can automatically persist. It takes care of writing everything. You don't need to write the mappings. Of course, you need to follow certain conventions in the names. SqueakSave supports MySQL and PostgreSQL only althought they wanted to interface with SqueakDBX to support all databases. I don't know neither if it works on Pharo. Of course, it seems to be a less slower than Glorp as the queries are not the faster. If I were you, for the screencast, I would really like to see the following scenario: you have a domain model and then you persists: 1) Image based / serializers (sixx, ImageSegments, SmartRefStream, etc) 2) OO database -> magma or GLASS 3) Relational database -> Glorp, SqueakSave, etc Each item can be a different post and for each item you show the advantages or disadvantages and of course, in each item, the domain model is the same. Of course this may require a lot of time and effort :) Uffff now I realized this is almost the same Torsted said. Sorry. Cheers Mariano 2010/2/17 laurent laffont <laurent.laffont(a)gmail.com> > Hi, > > I would like to learn on Pharo + databases. I've seen there's several > solutions in both object and relational databases. > - Which (open source) object database should I start with (most used) ? > - Which object database can be accessed from Smalltalk AND Ruby or Python > ? How ? > - I want to try MySQL too. > Is there up to date small applications on squeaksource which show this > stuff quite well ? > > Thanks for help ! > > Laurent Laffont > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 18, 2010

Re: [Pharo-project] databases

by Igor Stasenko

2010/2/18 laurent laffont <laurent.laffont(a)gmail.com>: > > On Wed, Feb 17, 2010 at 1:12 PM, Torsten Bergmann <astares(a)gmx.de> wrote: >> >> Hi Laurent, >> >> I think this topic or persistence in general would require more than >> one screencast to show people several options > > It's true ... but we need a first one on an option, then a second one on > another option ..... > I'm totally newbie on object databases, I want to learn, recording a > screencast is a way to learn. > If someone wants to help > :)Â http://pharocasts.blogspot.com/2010/02/how-i-record-screencasts-for-pharoca… > >> >> (like using the native >> Â drivers/database) up to higher level stuff mit OR mapping (Glorp) or >> Â Gemstone. >> >> Also well known (Oracle, MySQL, ...) vs. alternative databases (Magma, >> Â CouchDB, ...) or persistence in XML, ReferenceStreams, ... > > CouchDB looks good, it's on my to-look-at list... > Yeah, there are two Couchy interfaces for squeak on SqS. One is mine, which i started recently. Please try it out :) Any feedback is appreciated. >> >> Maybe SQLite could be used for a simple database example using >> Pharo and SQL. >> >> There is a metacello config for it: >> >> http://n4.nabble.com/ANN-SQLite3-wrapper-updated-with-tests-td1294969.html >> >> Have a look at the test cases to see some code. > > > I will ! Thanks > > Laurent Laffont > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 18, 2010

Re: [Pharo-project] {Spam?} Re: "Real" packages.

by Miguel Enrique CobÃ¡ Martinez

El jue, 18-02-2010 a las 12:18 -0800, Dale Henrichs escribiÃ³: > Gemstone uses an order list of dictionaries for global lookup. Each user can change the order of the list or insert their own dictionaries into the list ... makes for quite a bit of flexibility.... you can load code into a particular dictionary...and the global resolution is at compile time (you can do lookup at runtime if you wish). > > The advantage is that the code itself has no namespace artifacts at all. > > I'm mentioning this as a point of information more than a serious suggestion that Pharo adopt such an approach, though:) Why not, if it has been proved for a long time in Gemstone, shouldn't be sensible to create something similar for Pharo? Or it uses some kind of proprietary technology from Gemstone? Well just asking. Thanks > > Dale > > ----- "Wilhelm K Schwab" <bschwab(a)anest.ufl.edu> wrote: > > | Sorry, I can't resist exploiting the typo: the would be "grate" (vs. > | great) for me too. I also suspect that name spaces would turn into a > | horrible mess in short order. > | > | I could learn to live with messages as class names, something like > | > | Smalltalk goGators Dictionary etc. > | > | so that the "name space" is really an object accessed by a selector > | (#goGators above) and Dictionary then is a message to same. I got the > | idea from Dolphin. AFAIK, it has not gone terribly far, but my sense > | is that it does what one really needs from name spaces without > | inviting the slippery slope into Java packages. > | > | Bill > | > | > | -----Original Message----- > | From: pharo-project-bounces(a)lists.gforge.inria.fr > | [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > | Esteban Lorenzano > | Sent: Wednesday, February 17, 2010 3:40 PM > | To: pharo-project(a)lists.gforge.inria.fr > | Subject: Re: [Pharo-project] {Spam?} Re: "Real" packages. > | > | Well... I disagree with you, Mariano. If you allow packages, suddenly > | you will have things like: > | > | com.pirulo.Date, > | ar.com.pirulin.Date > | > | and a lot of classes who, in fact, should be just Date > | > | (and that's just an example) > | > | Cheers, > | Esteban > | > | On 2009-02-11 12:13:07 -0300, Mariano Martinez Peck > | <marianopeck(a)gmail.com> said: > | > | > > | > > | > I hate not having a real namespace. I hate to call my class > | > DBXConnection instead of Connection. I think namespaces are very > | > useful. Something like Java packages or similar would be grate for > | me. > | > > | > Cheers, > | > > | > Mariano > | > > | > On Tue, Feb 10, 2009 at 7:09 PM, Travis Kay <tlk(a)nb.sympatico.ca> > | > wrote: > | > > | >> Bill Schwab wrote: > | >>> Stef, > | >>> > | >>> Re Dolphin, class categories have long been of marginal use; I'll > | > | >>> speak > | >> for myself on that but suspect others would agree. > | >> I am a Dolphin Pro, Squeak and Pharo users, I agree. > | >> > | >> Travis > | >> > | >>> Packages are of course extremely useful. Method categories are > | also > | >> quite useful, and Dolphin allows multiple categories to be assigned > | > | >> to a given method. Dolphin mixes virtual categories (computed by > | >> rules) with static ones maintained by the user (and serialized as > | part of packages). > | >>> > | >>> I can easily see where OB would get quite a speed boost out of > | it. > | >>> > | >>> Bill > | >>> > | >>> > | >>> > | >>> > | >>> > | >>> Wilhelm K. Schwab, Ph.D. > | >>> University of Florida > | >>> Department of Anesthesiology > | >>> PO Box 100254 > | >>> Gainesville, FL 32610-0254 > | >>> > | >>> Email: bschwab(a)anest.ufl.edu > | >>> Tel: (352) 273-6785 > | >>> FAX: (352) 392-7029 > | >>> > | >>> > | >>> > | >>>>>> stephane.ducasse(a)inria.fr 2/10/2009 4:41:10 PM >>> > | >>>>>> > | >>> Alexandre implemented long time ago an hybrid model where both > | kind > | >>> of packages could coexist and we should probably revive it for > | 1.1 > | >>> > | >>> Stef > | >>> On Feb 10, 2009, at 10:28 PM, Michael van der Gulik wrote: > | >>> > | >>> > | >>>> On Wed, Feb 11, 2009 at 9:21 AM, David R=F6thlisberger > | >>>> <squeak@webcita= > | > s.ch > | >>>> > | >>>>> wrote: > | >>>>> > | >>>> So if we had real packages in Pharo as first class entities, OB > | >>>> would be much faster and simpler to maintain. Right now, OB > | models > | >>>> packages and class cats itself, has to take the information from > | > | >>>> both the Monticello's working copy managers and the > | >>>> SystemOrganizer. This is a mess and a huge pain, but what can we > | do. > | >>>> We should really invest in bringing real packages to Pharo. > | >>>> > | >>>> > | >>>> If you want "real" packages, I've implemented them in Squeak: > | >>>> > | >>>> http://gulik.pbwiki.com/Namespaces > | >>>> http://gulik.pbwiki.com/Packages > | >>>> > | >>>> The places the code is held, including a video and a Squeak image > | is > | >>>> linked from here: > | >>>> http://gulik.pbwiki.com/SecureSqueak > | >>>> > | >>>> I'm not interested in Pharo, but the code is there and is > | released > | >>>> under the MIT license if anybody else wants it. > | >>>> > | >>>> Gulik. > | >>>> > | >>>> -- > | >>>> http://people.squeakfoundation.org/person/mikevdg > | >>>> http://gulik.pbwiki.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 > | >>> > | >>> > | >>> _______________________________________________ > | >>> Pharo-project mailing list > | >>> Pharo-project(a)lists.gforge.inria.fr > | >>> > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | >>> > | -----------------------------------------------------------------------= > | > - > | >>> > | >>> > | >>> No virus found in this incoming message. > | >>> Checked by AVG - www.avg.com > | >>> Version: 8.0.233 / Virus Database: 270.10.20/1943 - Release Date: > | >> 02/10/09 07:20:00 > | >>> > | >>> > | >> > | >> > | >> _______________________________________________ > | >> Pharo-project mailing list > | >> Pharo-project(a)lists.gforge.inria.fr > | >> > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | >> > | > > | > > | > I hate not having a real namespace. I hate to call my class > | DBXConnection i= > | > nstead of Connection. I think namespaces are very useful. Something > | like Ja= > | > va packages or similar would be grate for me. > | Cheers, Marian= > | > o > | > <div class=3D"gmail_quote">On Tue, Feb 10, 2009 at 7:09 PM, > | Travis Kay = > | > <<a > | > > | href=3D"mailto:tlk@nb.sympatico.ca">tlk-F7KtY6MJiVI/4Up/o1S3Qw(a)public.gmane.org= > | co.ca</a>> > | > > | > wrote: <blockquote class=3D"gmail_quote" style=3D"b= > | > order-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; > | paddin= > | > g-left: 1ex;"> > | > <div class=3D"Ih2E3d">Bill Schwab wrote: > | > > Stef, > | > > > | > > Re Dolphin, class categories have long been of marginal use; > | I'll = > | > speak for myself on that but suspect others would agree. > | > </div>I am a Dolphin Pro, Squeak and Pharo users, I agree. > | > > | > Travis > | > <div><div></div><div class=3D"Wj3C7c"> > | > > Packages are of course extremely useful.  Method > | categories are a= > | > lso quite useful, and Dolphin allows multiple categories to be > | assigned to = > | > a given method.  Dolphin mixes virtual categories (computed by > | rules) = > | > with static ones maintained by the user (and serialized as part of > | packages= > | > ). > | > > | > > > | > > I can easily see where OB would get quite a speed boost out of > | it. > | > > > | > > Bill > | > > > | > > > | > > > | > > > | > > > | > > Wilhelm K. Schwab, Ph.D. > | > > University of Florida > | > > Department of Anesthesiology > | > > PO Box 100254 > | > > Gainesville, FL 32610-0254 > | > > > | > > Email: <a > | > href=3D"mailto:bschwab@anest.ufl.edu">bschwab(a)anest.ufl.edu<= > | /a> > | > > | > > | > Tel: (352) 273-6785 > | > > FAX: (352) 392-7029 > | > > > | > > > | > > > | > >>>> <a > | > href=3D"mailto:stephane.ducasse@inria.fr">stephane.duca= > | sse(a)inria.fr</a> > | > > | > 2/10/2009 4:41:10 PM >>> > | > >>>> > | > > Alexandre implemented long time ago an hybrid model where both > | kind of= > | > > | > > packages could coexist > | > > and we should probably revive it for 1.1 > | > > > | > > Stef > | > > On Feb 10, 2009, at 10:28 PM, Michael van der Gulik wrote: > | > > > | > > > | > >> On Wed, Feb 11, 2009 at 9:21 AM, David R=F6thlisberger > | <squeak@= > | > webcitas.ch > | > >> > | > >>> wrote: > | > >>> > | > >> So if we had real packages in Pharo as first class > | entities, OB<br= > | >> > | > >> would be much faster > | > >> and simpler to maintain. Right now, OB models packages and > | class<b= > | > r> > | > >> cats itself, has to > | > >> take the information from both the Monticello's working > | copy<b= > | > r> > | > >> managers and the > | > >> SystemOrganizer. This is a mess and a huge pain, but what > | can we d= > | > o. > | > >> We should really invest in bringing real packages to > | Pharo. > | > >> > | > >> > | > >> If you want "real" packages, I've implemented > | them i= > | > n Squeak: > | > >> > | > >> <a href=3D"http://gulik.pbwiki.com/Namespaces" > | target=3D"_blank">h= > | > ttp://gulik.pbwiki.com/Namespaces</a> > | > >> <a href=3D"http://gulik.pbwiki.com/Packages" > | target=3D"_blank">htt= > | > p://gulik.pbwiki.com/Packages</a> > | > >> > | > >> The places the code is held, including a video and a Squeak > | image = > | > is > | > >> linked from here: > | > >> <a href=3D"http://gulik.pbwiki.com/SecureSqueak" > | target=3D"_blank"= > | >> http://gulik.pbwiki.com/SecureSqueak</a> > | > >> > | > >> I'm not interested in Pharo, but the code is there and > | is rele= > | > ased > | > >> under the MIT license if anybody else wants it. > | > >> > | > >> Gulik. > | > >> > | > >> -- > | > >> <a > | href=3D"http://people.squeakfoundation.org/person/mikevdg" targ= > | > > | et=3D"_blank">http://people.squeakfoundation.org/person/mikevdg</a> > | > >> <a href=3D"http://gulik.pbwiki.com/" > | target=3D"_blank">http://guli= > | > k.pbwiki.com/</a> > | > >> _______________________________________________ > | > >> Pharo-project mailing list > | > >> <a > | > href=3D"mailto:Pharo-project@lists.gforge.inria.fr">Pharo-proje= > | ct(a)lists.gforge.inria.fr</a> > | >> > | > > | > <a href=3D"http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/p= > | > haro-project" > | target=3D"_blank">http://lists.gforge.inria.fr/cgi-bin/mailma= > | > n/listinfo/pharo-project</a> > | > >> > | > > > | > > > | > > _______________________________________________ > | > > Pharo-project mailing list > | > > <a > | > > | href=3D"mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@l= > | ists.gforge.inria.fr</a> > | > > | > > | > <a > | href=3D"http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo= > | > -project" > | target=3D"_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/li= > | > stinfo/pharo-project</a> > | > > > | > > > | > > _______________________________________________ > | > > Pharo-project mailing list > | > > <a > | > > | href=3D"mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project@l= > | ists.gforge.inria.fr</a> > | > > | > > | > <a > | href=3D"http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo= > | > -project" > | target=3D"_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/li= > | > stinfo/pharo-project</a> > | > </div></div>> > | ----------------------------------------------------------= > | > -------------- > | > > > | > > > | > > No virus found in this incoming message. > | > > Checked by AVG - <a href=3D"http://www.avg.com" > | target=3D"_blank">www.= > | > avg.com</a> > | > > Version: 8.0.233 / Virus Database: 270.10.20/1943 - Release > | Date: 02/1= > | > 0/09 07:20:00 > | > <div><div></div><div class=3D"Wj3C7c">> > | > > > | > > | > > | > _______________________________________________ > | > Pharo-project mailing list > | > <a > | > > | href=3D"mailto:Pharo-project@lists.gforge.inria.fr">Pharo-project(a)lists.= > | gforge.inria.fr</a> > | <a > | > > | > > | href=3D"http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-proj= > | > ect" > | target=3D"_blank">http://lists.gforge.inria.fr/cgi-bin/mailman/listinf= > | > o/pharo-project</a> > | > </div></div></blockquote></div> > | > > | > > | > > | > > | > _______________________________________________ > | > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Feb. 18, 2010

Re: [Pharo-project] cull: protocol

by StÃ©phane Ducasse

henrik I'm trying to get the pros and cons of cull: So am'I correct that this is useful only for situation where we have a block and we do not know upfront its number of argument: = places where valueWithPossibleArgs: Now what cull: offers is that the client does not have to create the array. I did not check your implementation. Stef On Feb 18, 2010, at 2:23 PM, Henrik Johansen wrote: > Refactoring the AXAnnouncements abit so there's no separate classes for > 0-, 1-, and 2-arg blocks, and really missing these methods from > VisualWorks... > cull: is equivalent to value: protocol except they accept block with N > or less blockArgs > Yes, I know valueWithEnoughArguments:/valueWithPossibleArgs: provide the > same functionality, but the code looks much less nice using them, you > end up constructing arrays needlessly etc. > Look at the senders of valueWithPossibleArgs: for examples, very few of > those actually need the ability to accept blocks with more arguments > than they provide, and would also look nicer with cull:. > > Would anyone object strongly to adding the cull:, cull:cull: methods in > core instead of putting them as extension methods? > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 18, 2010

Re: [Pharo-project] cull: protocol

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=1991 Purpose of code changes on this branch: Provide a cull: protocol on BlockClosure, equivalent to value: protocol, but taking N or more args, where N is numArgs. This is already provided by valueWithPossibleArgs:, but this only takes an array, and fills out missing arguments if block numArgs is higher than array size, as well as leading to extra syntax when your number of variable args is low and constant compared to cull: f.ex. ifNotNil: ifNotNilBlock ^ifNotNilBlock valueWithPossibleArgs: {self} turns into: ifNotNil: ifNotNilBlock ^ifNotNilBlock cull: self and: ifError: errorHandlerBlock ^ self on: Error do: [:ex | errorHandlerBlock valueWithPossibleArgs: {ex description. ex receiver}] turns into: ifError: errorHandlerBlock ^ self on: Error do: [:ex | errorHandlerBlock cull: ex description cull: ex receiver] When reviewing my code changes, please focus on: - Code clarity (there are speedier but uglier implementations) - Unnecessary array creation - Usefulness On Feb 18, 2010, at 2:23 PM, Henrik Johansen wrote: > Refactoring the AXAnnouncements abit so there's no separate classes for > 0-, 1-, and 2-arg blocks, and really missing these methods from > VisualWorks... > cull: is equivalent to value: protocol except they accept block with N > or less blockArgs > Yes, I know valueWithEnoughArguments:/valueWithPossibleArgs: provide the > same functionality, but the code looks much less nice using them, you > end up constructing arrays needlessly etc. > Look at the senders of valueWithPossibleArgs: for examples, very few of > those actually need the ability to accept blocks with more arguments > than they provide, and would also look nicer with cull:. > > Would anyone object strongly to adding the cull:, cull:cull: methods in > core instead of putting them as extension methods? > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 18, 2010

Re: [Pharo-project] Keyboard events issue on Mac VM

by John M McIntosh

You are mistaken in your interpretation of the event codes. please read http://isqueak.org/ioGetNextEvent You will find the windows VM will return Windows meta key codes which won't match the values for keyStroke Tweak in Croquet & Sophie uses KeyDown/keyUp for Tweak event handling and ignores keyStroke: On 2010-02-18, at 12:32 PM, Pavel Krivanek wrote: > Hi, > > The Mac OS virtual machine has wrong processing of keyUp and keyDown > events. It discards event character value. > > This events are very rarely used (keyStroke is preferred) so there`s > no surprise that it was not reported before. > > See http://code.google.com/p/pharo/issues/detail?id=1995 > > Cheers, > -- Pavel > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Feb. 18, 2010

[Pharo-project] self halt :)

by StÃ©phane Ducasse

Hi guys I do not know anything about BalloonBezierSimulation but it contains too many self halt. Do you have an idea if this is something that can be fixed? Stef

Feb. 18, 2010

[Pharo-project] Fwd: [squeak-dev] Re: ScriptLoader loadFFI doesn't work anymore

by Torsten Bergmann

Dale wrote: >In theory the Metacello configuration is created by the maintainers of the project Yes - in theory ;) >There's no question that the folks managing that repository had a good reason for >doing what they did, See http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-February/144628… >If Pharo has it's own repository for things like FFI, etc. then the problem of >disappearing packages shouldn't happen. Maybe by having an own SqS server (for Pharo only) with packages known to work (together with configurations). BTW: Linus on Git: http://www.youtube.com/watch?v=4XpnKHJAok8, interesting. Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser

Feb. 18, 2010