- Pharo-dev - lists.pharo.org

[Pharo-project] SimpleButtonMorph openInWorld

by DAE

This code makes a square button appear in the topleft corner SimpleButtonMorph new target: Smalltalk; label: 'Beep!'; actionSelector: #beep; openInWorld How do I make it go away? Sorry if I posted to the wrong group. If so, please tell me where is correct.

Jan. 28, 2011

Re: [Pharo-project] Issue 3599 in pharo: Serial Port

by Serge Stinckwich

On Fri, Jan 28, 2011 at 9:12 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Wed, Jan 26, 2011 at 03:09:14PM +0000, pharo(a)googlecode.com wrote: >> Status: Accepted >> Owner: stephane...(a)gmail.com >> Labels: Milestone-1.3 >> >> New issue 3599 by stephane...(a)gmail.com: Serial Port >> http://code.google.com/p/pharo/issues/detail?id=3599 >> >> Hello >> We are developing software to interact with small robots for educational >> purposes. To do this we need to use the serial port. SerialPort class that >> includes Pharo does not work on mac or linux, because it?s not Â able to >> open ports by name. > > FYI, the primitives for named serial ports are now in the standard VM > (maybe not yet in Cog, but it is a small change). If someone would like > to test on a Linux platform, try using any recent build of the standard > VM or use the latest 4.4.7.2357 unix VM from http://squeakvm.org/unix/. > > The image changes to SerialPort are simple. You can either copy changes > from Squeak or get the orginal change sets from the Mantis report at > http://bugs.squeak.org/view.php?id=7266. > > The named serial port work was contributed by Severin Lemaignan > <severin.lemaignan(a)laas.fr> and I helped with some of the integration. > Anything that I did is MIT licensed. Hi David, there is a issue in the Pharo bug tracker since several months for the integration of this changes into Pharo here: http://code.google.com/p/pharo/issues/detail?id=1057 Could we integrate these changes in 1.2 as there is no licence problems at all. David and SÃ©verin could you sign the licence agreement, just to be sure everything is ok. The quality of the code is not really good, there is a lot of isString everywhere in order to test if the port is a number or a string regarding the OS platform used: SerialPort>>close "Close the serial port. Do nothing if the port is not open." port ifNotNil: [port isString ifTrue:[self primClosePortByName: port] ifFalse:[self primClosePort:port]]. port := nil I think we need to polish it in order maybe to use only strings. Why not used string like 'COM1' for a windows platform and '/dev/ttyS*' for Linux ? Any comments about that ? Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Jan. 28, 2011

Re: [Pharo-project] Issue 3599 in pharo: Serial Port

by David T. Lewis

On Wed, Jan 26, 2011 at 03:09:14PM +0000, pharo(a)googlecode.com wrote: > Status: Accepted > Owner: stephane...(a)gmail.com > Labels: Milestone-1.3 > > New issue 3599 by stephane...(a)gmail.com: Serial Port > http://code.google.com/p/pharo/issues/detail?id=3599 > > Hello > We are developing software to interact with small robots for educational > purposes. To do this we need to use the serial port. SerialPort class that > includes Pharo does not work on mac or linux, because it?s not able to > open ports by name. FYI, the primitives for named serial ports are now in the standard VM (maybe not yet in Cog, but it is a small change). If someone would like to test on a Linux platform, try using any recent build of the standard VM or use the latest 4.4.7.2357 unix VM from http://squeakvm.org/unix/. The image changes to SerialPort are simple. You can either copy changes from Squeak or get the orginal change sets from the Mantis report at http://bugs.squeak.org/view.php?id=7266. The named serial port work was contributed by Severin Lemaignan <severin.lemaignan(a)laas.fr> and I helped with some of the integration. Anything that I did is MIT licensed. HTH, Dave

Jan. 28, 2011

Re: [Pharo-project] Databases with full text search support

by GÃ¶ran Krampe

Hi! I think the absolutely most interesting NoSQL DB with this in mind is Riak and its Riak Search. Google it. I have been itching to write a binding for Riak but have had no time to do it. Riak is built for "crazy just add another node" scaling and is modelled after Dynamo. Recently Riak Search was added, which is a Lucene compatible "overlay" for Riak thus giving you a free text search db with insane scalability and robustness. CouchDB does not have anything close to this scalability, unless you look at Cloudant perhaps - but AFAIK it does not have any kind of free text indexing. Yes, CouchDB has a Lucene integration (I have written a binding in C# for CouchDB and the Lucene integration) but we are still talking "single server" setup. MongoDB is fast as hell, but AFAIK also does not have free text engine nor the same "add another box" scalability like Riak has. regards, GÃ¶ran

Jan. 28, 2011

Re: [Pharo-project] Issue 3603 in pharo: O/ECompletion failure in Trait methods

by Levente Uzonyi

On Thu, 27 Jan 2011, Henrik Sperre Johansen wrote: > On 27.01.2011 19:53, Levente Uzonyi wrote: >> On Thu, 27 Jan 2011, pharo(a)googlecode.com wrote: >> >>> Status: Accepted >>> Owner: ryd...(a)gmail.com >>> CC: romain.r...(a)gmail.com >>> Labels: Milestone-1.2-DevImage Milestone-1.3-DevImage OCompletion >>> >>> New issue 3603 by ryd...(a)gmail.com: O/ECompletion failure in Trait methods >>> http://code.google.com/p/pharo/issues/detail?id=3603 >>> >>> A debugger pops up when typing in after super in a trait method, since >>> traits do not implement superclass. >> >> The bug is not related to OCompletion. Traits implement (via TPureBehavior) >> #allSuperclasses, #withAllSuperclasses, etc., but lack >> #superclass. > So which implementation of #superclass would you recommend for Trait, which > would keep O/ECompletion working without modification? > I can't think of any which makes sense really. > > IMO, if code in the component eventually needs to be changed to not raise a > debugger, it's related. Okay, I added a check for this. It's in Ocompletion-ul.91. Levente > > Cheers, > Henry > >

Jan. 28, 2011

Re: [Pharo-project] Databases with full text search support

by Miguel CobÃ¡

El jue, 27-01-2011 a las 18:24 -0500, Dmitri Zagidulin escribiÃ³: > As far as bindings for MongoDB, if you're referring to > http://www.squeaksource.com/MongoTalk - though it's an excellent > start, it is not quite production ready. In that - > only the MongoDB equivalents of 'select' and 'insert' have been > implemented, but not update or delete. I'm working on implementing > those operations right now & submitting a patch, and should have a > post up about it in a > couple of weeks. But Mongo is not yet in the running, for full text search. Oh, good to know. -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 28, 2011

Re: [Pharo-project] Databases with full text search support

by Dmitri Zagidulin

As far as bindings for MongoDB, if you're referring to http://www.squeaksource.com/MongoTalk - though it's an excellent start, it is not quite production ready. In that - only the MongoDB equivalents of 'select' and 'insert' have been implemented, but not update or delete. I'm working on implementing those operations right now & submitting a patch, and should have a post up about it in a couple of weeks. But Mongo is not yet in the running, for full text search. Dmitri Zagidulin http://smalltalkzen.wordpress.com On Thu, Jan 27, 2011 at 2:58 PM, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > There isn't a full solution that I know of, but maybe you can use lucene > to store index info outside smalltalk and use the references to search > for the real smalltal objects. > > There are also bindings for several nosql databases for lucene and solr > like mongo db and cassandra and there are bindings in smalltalk for > mondodb and cassandra. > > Cheers > > El jue, 27-01-2011 a las 20:48 +0100, laurent laffont escribiÃ³: >> Hi, >> >> >> I need to have full text indexing and searching over a 3-5 million >> documents. Actually the products I work on are written in PHP - >> MySQL. >> >> >> What would you use (open source - mandatory - our products are open >> source) in Smalltalk world Â to do this ? >> >> Laurent Laffont - @lolgzs >> >> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ >> Blog: http://magaloma.blogspot.com/ >> > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > >

Jan. 27, 2011

Re: [Pharo-project] About FileSystem (probably not for 1.3)

by Dale Henrichs

On 01/27/2011 03:00 PM, Lukas Renggli wrote: >> I started to merge some of your changes to FS. > > I already merged most of the changes of Max into the main code. > >> Now I was wondering about this one: >> ***for my work on GitFS I needed a resumable exception (alternatively an ifPresent block would have done the trick but that would have ment more meddling with Filesystem) to delete existing files when copying. The following changes are a result of introducing this exception to the copy methods. >> *added class FSFileExistsResumbale and its superclass FSFilesystemException to support the changes to the copy methods >> *#copy:to: signals FSFileExistsResumbale instead of FSFileExists >> *FSCopyVisitor>>copyDirectory uses #ensureDirectory instead of #createDirectory >> *needed to change FSFilesystemTest>>testCopyDestExists to expect FSFileExistsResumable >> *FSReference>>basicCopyTo: signals FSFileExistsResumable instead of FSFileExists >> >> Could you explain us a bit more? > > This is not something that should go into the main code. If I remember > correctly this was a quick hack to avoid some problems in GitFS. > > Lukas > At the time I ported FileSystem to GemStone (4 months ago?), I started with the packages in Lukas' repository... Dale

Jan. 27, 2011

Re: [Pharo-project] About FileSystem (probably not for 1.3)

by Lukas Renggli

> I started to merge some of your changes to FS. I already merged most of the changes of Max into the main code. > Now I was wondering about this one: > ***for my work on GitFS I needed a resumable exception (alternatively an ifPresent block would have done the trick but that would have ment more meddling with Filesystem) to delete existing files when copying. The following changes are a result of introducing this exception to the copy methods. > *added class FSFileExistsResumbale and its superclass FSFilesystemException to support the changes to the copy methods > *#copy:to: signals FSFileExistsResumbale instead of FSFileExists > *FSCopyVisitor>>copyDirectory uses #ensureDirectory instead of #createDirectory > *needed to change FSFilesystemTest>>testCopyDestExists to expect FSFileExistsResumable > *FSReference>>basicCopyTo: signals FSFileExistsResumable instead of FSFileExists > > Could you explain us a bit more? This is not something that should go into the main code. If I remember correctly this was a quick hack to avoid some problems in GitFS. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 27, 2011

Re: [Pharo-project] About FileSystem (probably not for 1.3)

by Dale Henrichs

Sounds good ... I'll work through the changes that I've made and try to extract out the goodness and then provide suggested changes (in the form of an mcz file you can merge if the changes make sense to you)... BTW, I used the FileSystem port with a Monticello port (replacing all of the FileDirectory stuff with FileSystem calls) and the Monticello port was based on a fairly recent Pharo version of Monticello:) Dale On 01/27/2011 01:34 PM, StÃ©phane Ducasse wrote: > I'm. :) > I do not want differences for the shake for them. I want an excellent system. > I'm working on PharoTaskForces so if you can merge step by step it would be great. > > Stef > > > On Jan 27, 2011, at 10:31 PM, Dale Henrichs wrote: > >> Stef, >> >> I have ported FileSystem to GemStone, but I had to make a number of changes that were necessary to improve the portability (at least for GemStone) ... It would be a bit of work for me to extract the changes, but I'd be willing to do it if you were interested in incorporated some of them (if not all) ... >> >> Dale >> >> On 01/27/2011 12:58 PM, StÃ©phane Ducasse wrote: >>> Hi max >>> >>> I started to merge some of your changes to FS. >>> Now I was wondering about this one: >>> >>> ***for my work on GitFS I needed a resumable exception (alternatively an ifPresent block would have done the trick but that would have ment more meddling with Filesystem) to delete existing files when copying. The following changes are a result of introducing this exception to the copy methods. >>> *added class FSFileExistsResumbale and its superclass FSFilesystemException to support the changes to the copy methods >>> *#copy:to: signals FSFileExistsResumbale instead of FSFileExists >>> *FSCopyVisitor>>copyDirectory uses #ensureDirectory instead of #createDirectory >>> *needed to change FSFilesystemTest>>testCopyDestExists to expect FSFileExistsResumable >>> *FSReference>>basicCopyTo: signals FSFileExistsResumable instead of FSFileExists >>> >>> Could you explain us a bit more? >>> >>> Stef >>>> >>> >> >

Jan. 27, 2011