- Pharo-dev - lists.pharo.org

[Pharo-project] [update 1.2] #12325

by Marcus Denker

12325 ----- Issue 2586: line breaks lost on Linux when copying from one pharo image to another -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Jan. 28, 2011

Re: [Pharo-project] Issue 2586 in pharo: line breaks lost on Linux when copying from one pharo image to another

by pharo＠googlecode.com

Updates: Labels: Milestone-1.3 Comment #9 on issue 2586 by marcus.d...(a)gmail.com: line breaks lost on Linux when copying from one pharo image to another http://code.google.com/p/pharo/issues/detail?id=2586 in 12325 TODO: 1.3

Jan. 28, 2011

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

by S Krish

I would recommend using Lucene indexing for the documents for various reasons.. not limited to the fact that if one is interested in indexing documents and millions of them.. it obviates talking of Databases... Now with Lucene, I would recommend using the Groovy bridge with XMLRpc from Pharo to be able to do anything you may want to pass back n forth the path to the documents.. and the fileentry properties of the document found through the indexed search.. Coincidentally, I have been intending to complete the half done work on this.. for last one year.. for our internal div..! -Skrish On Fri, Jan 28, 2011 at 11:53 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Fri, Jan 28, 2011 at 9:54 AM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> Indeed actually we use successfully MySQL full text search engine and also >> Lucene (but not with Pharo ;) >> >> I think I should try OpenDBX. >> >> > You can also try the native MySQL client for Squeak. Not sure about its > current state, but you don't need any library. > http://www.squeaksource.com/MySQL.html > > For SqueakDBX, check everything in www.squeakdbx.org > > >> Laurent >> >> >> >> On Fri, Jan 28, 2011 at 3:44 PM, Mariano Martinez Peck < >> marianopeck(a)gmail.com> wrote: >> >>> Laurent: several relational databases provvide full text serach >>> capabilities. >>> >>> You can send a SELECT statement with a MATCH() function to the server and >>> get >>> the result of search back (in case of MySQL). I think OpenDBX >>> library has to do nothing special here: it depends on which query you >>> write. >>> >>> >>> MySQL and PostgreSQL server has support for full text search (aka. >>> tsearch in PostgreSQL I think). >>> >>> >>> cheers >>> >>> mariano >>> >>> >>> On Fri, Jan 28, 2011 at 3:57 AM, Norbert Hartl <norbert(a)hartl.name>wrote: >>> >>>> >>>> On 27.01.2011, at 20:48, laurent laffont wrote: >>>> >>>> > 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 ? >>>> > >>>> That topic troubled me some time in the last years. The first approach I >>>> took was postgresql+tsearch2 because I used Glorp back then. AFAIK tsearch2 >>>> has been incorporated into postgresql in the meantime so this is no extra >>>> weight. Stemming libraries for postgresql are quite good and available for >>>> some languages. If you would use Glorp you can even extend the query >>>> language to support it out of the box. >>>> I changed the setup as I moved from postgresql to gemstone. With the new >>>> setup I would have used postgresql only for the fulltext retrieval which I >>>> didn't like. I used SOLR [1] instead. It is a search server build upon >>>> lucene which supports faceted search and a lot of nifty stuff. I used >>>> magritte to generate the xml that I've put into SOLR. I was satisfied with >>>> this solution. But all solutions that need to cross the smalltalk boundary >>>> start to become cumbersome at some stage. >>>> If I find time I would take another approach. I found a smalltalk >>>> stemming library while observing the moose mailing list. If you have good >>>> stemming support it may be a reasonable effort to produce forward and >>>> inverted indexes of your objects with search capabilities. If you use >>>> magritte (or pragmas) then you could add the fields to index there. The rest >>>> would be automatic: Taking all fields that should be searchable. Tokenize >>>> and canonicalize (using stemming) the words and build forward and inverted >>>> index. The only thing that would be needed is a change notification system >>>> that updates the index but I think this is more of an easy task. Well, that >>>> is the sketch what I would try to do myself but don't find time right now. I >>>> personally think that the power you gain by search smalltalk objects >>>> directly outweighs all the external servers by some extent. >>>> If you use a special external database anyway that supports it, well, >>>> then this would be the easiest start. >>>> >>>> hope this helps, >>>> >>>> Norbert >>>> >>>> >>>> >>>> >>> >> >

Jan. 28, 2011

Re: [Pharo-project] does anybody knows who is using StandardToolSet?

by Igor Stasenko

On 28 January 2011 19:20, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > yes, check the archives. I opened tickes for that. and I sent several mails. > Seems no-one has time to do it. > we discussed that today. probably i will take care about it for 1.3.. not sure how soon it will be but i will :) > http://code.google.com/p/pharo/issues/detail?id=1915 > > On Fri, Jan 28, 2011 at 10:44 AM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> Because it would be good that it uses a registration mechanism. >> Hardcoding the classes of the tools is not optimal for example for the new >> Finder. >> >> Stef > > -- Best regards, Igor Stasenko AKA sig.

Jan. 28, 2011

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

by Mariano Martinez Peck

On Fri, Jan 28, 2011 at 9:54 AM, laurent laffont <laurent.laffont(a)gmail.com>wrote: > Indeed actually we use successfully MySQL full text search engine and also > Lucene (but not with Pharo ;) > > I think I should try OpenDBX. > > You can also try the native MySQL client for Squeak. Not sure about its current state, but you don't need any library. http://www.squeaksource.com/MySQL.html For SqueakDBX, check everything in www.squeakdbx.org > Laurent > > > > On Fri, Jan 28, 2011 at 3:44 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Laurent: several relational databases provvide full text serach >> capabilities. >> >> You can send a SELECT statement with a MATCH() function to the server and >> get >> the result of search back (in case of MySQL). I think OpenDBX >> library has to do nothing special here: it depends on which query you >> write. >> >> >> MySQL and PostgreSQL server has support for full text search (aka. >> tsearch in PostgreSQL I think). >> >> >> cheers >> >> mariano >> >> >> On Fri, Jan 28, 2011 at 3:57 AM, Norbert Hartl <norbert(a)hartl.name>wrote: >> >>> >>> On 27.01.2011, at 20:48, laurent laffont wrote: >>> >>> > 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 ? >>> > >>> That topic troubled me some time in the last years. The first approach I >>> took was postgresql+tsearch2 because I used Glorp back then. AFAIK tsearch2 >>> has been incorporated into postgresql in the meantime so this is no extra >>> weight. Stemming libraries for postgresql are quite good and available for >>> some languages. If you would use Glorp you can even extend the query >>> language to support it out of the box. >>> I changed the setup as I moved from postgresql to gemstone. With the new >>> setup I would have used postgresql only for the fulltext retrieval which I >>> didn't like. I used SOLR [1] instead. It is a search server build upon >>> lucene which supports faceted search and a lot of nifty stuff. I used >>> magritte to generate the xml that I've put into SOLR. I was satisfied with >>> this solution. But all solutions that need to cross the smalltalk boundary >>> start to become cumbersome at some stage. >>> If I find time I would take another approach. I found a smalltalk >>> stemming library while observing the moose mailing list. If you have good >>> stemming support it may be a reasonable effort to produce forward and >>> inverted indexes of your objects with search capabilities. If you use >>> magritte (or pragmas) then you could add the fields to index there. The rest >>> would be automatic: Taking all fields that should be searchable. Tokenize >>> and canonicalize (using stemming) the words and build forward and inverted >>> index. The only thing that would be needed is a change notification system >>> that updates the index but I think this is more of an easy task. Well, that >>> is the sketch what I would try to do myself but don't find time right now. I >>> personally think that the power you gain by search smalltalk objects >>> directly outweighs all the external servers by some extent. >>> If you use a special external database anyway that supports it, well, >>> then this would be the easiest start. >>> >>> hope this helps, >>> >>> Norbert >>> >>> >>> >>> >> >

Jan. 28, 2011

Re: [Pharo-project] does anybody knows who is using StandardToolSet?

by Mariano Martinez Peck

yes, check the archives. I opened tickes for that. and I sent several mails. Seems no-one has time to do it. http://code.google.com/p/pharo/issues/detail?id=1915 On Fri, Jan 28, 2011 at 10:44 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Because it would be good that it uses a registration mechanism. > Hardcoding the classes of the tools is not optimal for example for the new > Finder. > > Stef >

Jan. 28, 2011

Re: [Pharo-project] Issue 3618 in pharo: logError: aString inContext: aContext to: is used and it is deprecated

by pharo＠googlecode.com

Comment #1 on issue 3618 by gazzagu...(a)googlemail.com: logError: aString inContext: aContext to: is used and it is deprecated http://code.google.com/p/pharo/issues/detail?id=3618 Also, (self class context: aContext) should just be (self context: aContext) Additionally, the ErrorRecursion maybe should be set before the first lines, I am unable to load updates due to recursion (via the deprecation)... Perhaps this is all now horribly broken...

Jan. 28, 2011

Re: [Pharo-project] SimpleButtonMorph openInWorld

by csrabak＠bol.com.br

OTOH, For cases like that I think the best is to attribute the result of "SimpleButtonMorph new..." to a variable and the just use the message delete on this variable... my 0.019999... -- Cesar Rabak Em 28/01/2011 04:17, Fernando Olivero < fernando.olivero(a)usi.ch > escreveu: You can also evaluate the following expresions in a wokspace, SimpleButtonMorph allInstances do:[:each| each delete]. or | buttons | buttons := World submorphs detect:[:each| each isKindOf: SimpleButtonMorph ] . buttons anyOne delete. But i also prefer Serge option, because Morphs are directly manipulable for a reason! Fernando On Fri, Jan 28, 2011 at 2:49 AM, Serge Stinckwich wrote: > On Fri, Jan 28, 2011 at 9:40 AM, DAE wrote: >> 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. > > On my macintosh, CTRL+ right mouse button > and select the delete item. > > 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] [squeak-dev] Accessing external resources in a cross-platform way

by HernÃ¡n Morales Durand

Thanks David, I've seen FileSystem package http://www.wiresong.ca/filesystem/ it seems related in some way too 2011/1/28 David T. Lewis <lewis(a)mail.msen.com>: > On Fri, Jan 28, 2011 at 01:51:22PM +0100, Hern??n Morales Durand wrote: >> Let's say you want to resolve paths in a cross platform way >> >> Binaries @ 'MyExec' >> Libraries @ 'MyLib' >> SystemLibraries @ 'SystemLib' >> etc. >> >> then Binaries is >> >> In Windows: #( 'C:\Program Files\' 'C:\Archivos de Programa\' ...) " >> and all standard locations including translations " >> In UNIX: #('/usr/bin/' '/usr/local/bin' ....) " and all standard locations " >> etc >> >> Now you may say it is necessary to scan all directories to find >> MyExec, yes but you may then save that location >> >> myBinaryLocation := Binaries @ 'MyExec'. >> >> so you scan for it just once. >> >> What do you think? it is already implemented anywhere? >> If not what package do you think is more suitable or prepared for >> implementing it? > > Hern??n, > > This is of course very platform dependent, and it is more complex > than you might expect due to differences in file systems, operating > systems, volume names (windows), environment variables and search > path conventions. > > Both Windows and Unix use various seach paths accessible through > environment variables, and the conventions for this tend to change > over time with different OS versions. So it would probably be best > to rely directly on those environment variables for identifying > search paths. > > Aside from the conventions for default locations and search paths, > some of what you are looking for may also be implemented for Windows > and Unix in SqS/CommandShell in class ShellSyntax: > > Â My instances implement parsing of strings in a manner similar to > Â a simple Unix command shell. I provide path name expansion in the > Â context of an external file system, and support the syntax required > Â for IO redirection. All file name globbing and PATH searching are > Â implemented in Smalltalk rather than in C library functions or an > Â external command shell. > > Â Most of my syntax is applicable for any operating system. Where > Â needed, platform specific methods are in my "platform dependent" > Â category. Currently, Unix and Windows are supported, and other > Â platforms have not been tested. The primary difference between > Â Unix and Windows support is that device names (such as 'C:') are > Â used in Windows path strings. Separate current working directory > Â strings are maintained for all Windows device names. For Unix, > Â a single current working directory path is used. On Windows, > Â this permits the CommandShell 'cd' command to support changing > Â directories to another device without losing track of the current > Â working directory for the previous device. > > Â Command pipeline syntax is not supported here. See CommandShell > Â for the implementation of command pipelines. > > Dave > > >

Jan. 28, 2011

Re: [Pharo-project] Issue 3609 in pharo: Integrate RPackage

by pharo＠googlecode.com

Comment #2 on issue 3609 by tudor.gi...(a)gmail.com: Integrate RPackage http://code.google.com/p/pharo/issues/detail?id=3609 The decision in RPackage is to match categories 1-to-1 to packages. Thus, an RPackage will not have subcategories.

Jan. 28, 2011