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

Re: [Pharo-project] Ring - model infrastructure for Pharo

by Marcus Denker

> the format is different for RecentMessageList > 'Class >> #selector' > 'Class(removed) >> #selector' > Is this class being used? Or its method #removeAMethod: ? > I just noticed > that it is invoking #methodSymbol: from MethodReference, but that method > does not exist... > Without this, in fact we don't need an iVar, and we should manage an unique > format Hmm... that looks strange. In general, MethodReference should not seen as something defining what a general model needs, as it is in itself very strange and ugly. We need to carefully check. The use of RecentMessageList seems to be more that it needs a general way to associate meta-data with a reference ("I deleted this"). We should check the new stuff regarding RecentMessages that Benjamin did. Lots of the old things should be removed... -- Marcus DenkerÂ --Â denker(a)acm.org http://www.marcusdenker.de

Dec. 13, 2010

Re: [Pharo-project] Issue 3407 in pharo: HashedCollection missed abstract method noCheckAdd:

by pharo＠googlecode.com

Comment #1 on issue 3407 by rydier: HashedCollection missed abstract method noCheckAdd: http://code.google.com/p/pharo/issues/detail?id=3407 Alternatively change #grow to read: self growTo: self growSize. and #rehash self growTo: array size. This would be part of the synch up with HashedCollection improvements from squeak, as described in http://code.google.com/p/pharo/issues/detail?id=2551 . IIRC, step one as mentioned there (and introduced in core) stopped just short of switching these two methods over (to not have to deal with load orders of simultaniously introduced growTo: ), all methods part of growTo: should already be in image, and work correctly.

Dec. 13, 2010

[Pharo-project] Issue 3407 in pharo: HashedCollection missed abstract method noCheckAdd:

by pharo＠googlecode.com

Status: Accepted Owner: step...(a)stack.nl New issue 3407 by step...(a)stack.nl: HashedCollection missed abstract method noCheckAdd: http://code.google.com/p/pharo/issues/detail?id=3407 HashedCollection grow calls noCheckAdd: All direct subclasses implement noCheckAdd: Pharo image: core Pharo core version: 12272 Add the following method to HashedCollection: noCheckAdd: anObject self subclassResponsibility

Dec. 13, 2010

[Pharo-project] I am a genius

by Norberto Manzanos

Yes, I am. I can teach people how to write. Look, this is the unique class with only one method of my AI system: LinTirany >> analize: aString | errors | errors:= OrderedCollection new. #('would' 'very' ) do:[:each | (aString substrings includes: each) ifTrue:[ errors add: 'Avoid ',each]]. aString substrings size > 40 ifTrue:[errors add: 'Avoid long sentences']. ^errors Try it at http://textlint.lukas-renggli.ch and becomes an expert article writer. -- Norberto Manzanos Instituto de Investigaciones en Humanidades y Ciencias Sociales (IdIHCS) FaHCE/UNLP - CONICET Calle 48 e/ 6 y 7 s/NÂº - 8Âº piso - oficina 803 Tel: +54-221-4230125 interno 262

Dec. 13, 2010

Re: [Pharo-project] Ring - model infrastructure for Pharo

by Veronica Isabel Uquillas Gomez

On 13 Dec 2010, at 12:40, Marcus Denker wrote: > > On Dec 10, 2010, at 2:33 PM, Veronica Isabel Uquillas Gomez wrote: > >> Dear all, >> >> I am currently working on the Ring, an unifying and foundational model infrastructure for Pharo. >> The goals are: >> - Provide a common API at structural and runtime level >> - Allow tools to interact and integrate directly with the host environment (Pharo) >> - Support history analysis >> >> I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. >> So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes. >> >> An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). >> As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file). >> > #stringVersionDefault has just one sender (#markMatchingClasses in SelectorBrowser). Do we need that? > > In general, #stringVersion in MethodReference seems to be strange... > > stringVersion: 'Class>>selector:' format > > why is there an iVar for this? Can't this just use the selector and class an build it? the format is different for RecentMessageList 'Class >> #selector' 'Class(removed) >> #selector' Is this class being used? Or its method #removeAMethod: ? I just noticed that it is invoking #methodSymbol: from MethodReference, but that method does not exist... Without this, in fact we don't need an iVar, and we should manage an unique format > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. >

Dec. 13, 2010

Re: [Pharo-project] Ring - model infrastructure for Pharo

by Marcus Denker

On Dec 10, 2010, at 2:33 PM, Veronica Isabel Uquillas Gomez wrote: > Dear all, > > I am currently working on the Ring, an unifying and foundational model infrastructure for Pharo. > The goals are: > - Provide a common API at structural and runtime level > - Allow tools to interact and integrate directly with the host environment (Pharo) > - Support history analysis > > I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. > So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes. > > An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). > As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file). > #stringVersionDefault has just one sender (#markMatchingClasses in SelectorBrowser). Do we need that? In general, #stringVersion in MethodReference seems to be strange... stringVersion: 'Class>>selector:' format why is there an iVar for this? Can't this just use the selector and class an build it? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 13, 2010

Re: [Pharo-project] About using pragma for help like in setting

by StÃ©phane Ducasse

see my previous mail :) Stef On Dec 13, 2010, at 10:39 AM, laurent laffont wrote: > On Mon, Dec 13, 2010 at 9:56 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I read all the Help on Help and could not find what I wanted to know. > > What do you want to know / looking for ? > > Laurent > > > I read also the code same here. > > Stef > > > On Dec 12, 2010, at 10:33 AM, laurent laffont wrote: > > > > > I think, the fact that there is no single external package with help > > system documentation proves this, no? > > > > > > Actually there's at least Help on HelpSystem ;) ProfStef, WebTester, Metacello, Mocketry, Mondrian. I've started one for Pier but on Seaside mailing-list nobody have answered :( > > > > So yes there's some help, it's slow. > > > > I agree 100% on what you said about dependencies, documentation close to code, tagging/pragma approach, .... but it seems to me that whatever system we adopt, growing documentation will be slow . > > > > So we need to push to write doc. even if the current or futures systems are not perfect. > > > > Laurent. > > > > > > > > Lukas > > > > -- > > Lukas Renggli > > www.lukas-renggli.ch > > > > > > >

Dec. 13, 2010

Re: [Pharo-project] Issue 3406 in pharo: Standard images from downloads page do not implement Object #clone

by pharo＠googlecode.com

Comment #5 on issue 3406 by rydier: Standard images from downloads page do not implement Object #clone http://code.google.com/p/pharo/issues/detail?id=3406 It's resolved there exactly as steph describes btw.

Dec. 13, 2010

Re: [Pharo-project] Is executing a file platform dependent?

by Max Leske

Thanks for the answers. That should do. Cheers, Max On 13.12.2010, at 09:54, StÃ©phane Ducasse wrote: > Guys > > we should create a nice documentation for the OSProcess please please spend some time on the collabactive book because we need more documentation. > > Stef > > On Dec 12, 2010, at 6:34 PM, Schwab,Wilhelm K wrote: > >> OSProcess, which I am learning to like more as I learn more about it, is not well supported on Windows. Dave recently advised me to use ProcessWrapper on Windows; if he is saying that, then it must be the better path for now. >> >> I have done FFI on both Windows and Linux. I have not (yet anyway) done any one task in a cross-platform way. So far, I have not seen anything horrible that would prevent it. I have zero interest (at least so far) in moving my numerical analysis adventures back toward Windows (they started there and moved to Linux where I am quite happy). I have a .so interface to Acces IO A/D hardware and a DLL interface to Ascension Technology's 3D tracking software. Ultimately, I hope to be able to use both of them on either platform (the software exists on both), but have not yet made the connections. >> >> I transparently use OutputDebugString() on Linux and syslog() on Linux, but that does a test on platform and calls completely different code, so it does not count here. >> >> Sorry I can't be of more help. I urge you to wade into it and ask for help as you get stuck. For creating libraries, you might want to have a look at Code::Blocks; I don't push it very hard, but I have no complaints. The "default" is to install MinGW on Windows (last time I looked at least) and it uses gcc on Linux. >> >> Bill >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli(a)gmail.com] >> Sent: Sunday, December 12, 2010 11:43 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Is executing a file platform dependent? >> >> With OS Process you can run scripts. That should work identical on Mac >> and Unix systems; probably also Windows, but I haven't tried. >> >> With FFI and Alien you can call C libraries. I have not much >> experience with those, but normally it should be possible to use them >> on all platforms. >> >> Lukas >> >> On 12 December 2010 17:31, Max Leske <maxleske(a)gmail.com> wrote: >>> Hi guys >>> >>> I was wondering if it is true that executing a file from within Pharo is platform dependent. I don't actually need to execute a file; it's more a theoretical question and I have no idea what the mechanisms are that would be used. To give you a clearer picture: Imagine you have C, sh, and perl files. What I'm thinking about is that I would have some data in the image that I would want to process with the code in one of those files. I would then wait for the result and process the result in the image. >>> >>> So my questions are: is there a platform independent way to execute C, sh or perl files from Pharo? Does the VM handle the platform dependencies? Are there any other issues with the idea I described? >>> >>> Don't go out of your way to find answers, please. But I'd be happy to hear your thoughts. >>> >>> Cheers, >>> Max >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> > >

Dec. 13, 2010

Re: [Pharo-project] Issue 3406 in pharo: Standard images from downloads page do not implement Object #clone

by pharo＠googlecode.com

Comment #6 on issue 3406 by rydier: Standard images from downloads page do not implement Object #clone http://code.google.com/p/pharo/issues/detail?id=3406 It's resolved there exactly as steph describes btw.

Dec. 13, 2010