- Pharo-dev - lists.pharo.org

Re: [Pharo-project] do we need handleDisabledKey:

by StÃ©phane Ducasse

Yes it is a polymorph features. I ask gary to have a look when he has time. Stef On Sep 25, 2010, at 10:52 PM, Guillermo Polito wrote: > I had a look at CUIS, and it doesn't use it neither. > > On Fri, Sep 24, 2010 at 3:01 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > hi gary > > do we need handleDisabledKey: because this is not defined on the new editorHierarchy? > > http://code.google.com/p/pharo/issues/detail?id=3003 > > 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

Sept. 26, 2010

Re: [Pharo-project] In Smalltalk you can't loose code... hum

by StÃ©phane Ducasse

> > > > > Because in the script manager has a save capability, would it be difficult to write the changes into the changes files ? > > the problem is that the change files logic is old and it works 'well' for what it should but extending it will break other part. > This is why slowly we will have to think to get something better. > > Do you mean improving the change scanner parsing or throwing away and going for something different? > Hi eliot our vision is that we would like to have - all the code of all the squeak and pharo version in a queryable service available from the web. for that we want a source code metamodel a la ginsu or famix Use this metamodel to aggregate several meta models: pseudo class/rb make sure that when possible this model as a compative API with the one of classes and friends => tools reuse Veronica is working on that. Hernan will probably join. May be Colin should join. We could have a nice momentum. - for the changes we would like to have something else than a chunk format because invoking the parser to know if we are manipulating a class definition is bad (with token at: 2 do that and token at: 3 do that). Again it will take time but we should have a good (why not 'exquise') infrastructure so that we extend and build new tool easily. Stef

Sept. 26, 2010

Re: [Pharo-project] After loading a package...all changes with "revision changed"

by StÃ©phane Ducasse

Thanks!!! Because this bug is annoying. At one point we will have to dive into MC :). So many things to do. ;) Stef > We had a similar problem in squeaknos package, but just for some kind of classes. It was caused by having an initialize class method in classes derived from ExternalStructure, maybe it's because of the same reason? look there, you may get some answers. > > regards, > javier. > > 2010/9/26 Norbert Hartl <norbert(a)hartl.name> > FYI I encountered the same problem in gemstone. The only thing I know is that all loaded packages were created in pharo that showed this behaviour. It didn't show up in a reproducable manner and some packages were clean again after a few package updates. And for some month now I didn't see it. > > Norbert > > > Am 25.09.2010 um 21:12 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> On Sat, Sep 25, 2010 at 9:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote: >> >> > Hi. I am having a probem with Glorp and I really have no idea what can be. The problem is that I load the package Glorp and just after loading, I do a "changes" in the MC Browser and I see a lot of classes with a lot of changes and all of them like "revison changed". This is annoying since it doesn't let me easily see what I have really changed. >> > >> > To reproduce: >> > >> > - Load the package "Glorp" from http://www.squeaksource.com/SqueakDBX >> > - Open a MC Browser, select Glorp package and press the "Changes" button agains the ss repo. And you will see :) >> >> May be the image used to save the package got a problem and changed the timestamp of the methods. >> So when you merge you get changed methods. >> >> I've just tried commiting and load them in a clean image...same problem. >> >> And if it were what you say...is there a solution? >> >> thanks >> >> mariano >> >> >> > >> > Any help is really appreaciated. >> > >> > Thanks >> > >> > Mariano >> > _______________________________________________ >> > 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 > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 26, 2010

Re: [Pharo-project] After loading a package...all changes with "revision changed"

by Javier PimÃ¡s

We had a similar problem in squeaknos package, but just for some kind of classes. It was caused by having an initialize class method in classes derived from ExternalStructure, maybe it's because of the same reason? look there, you may get some answers. regards, javier. 2010/9/26 Norbert Hartl <norbert(a)hartl.name> > FYI I encountered the same problem in gemstone. The only thing I know is > that all loaded packages were created in pharo that showed this behaviour. > It didn't show up in a reproducable manner and some packages were clean > again after a few package updates. And for some month now I didn't see it. > > Norbert > > > Am 25.09.2010 um 21:12 schrieb Mariano Martinez Peck < > marianopeck(a)gmail.com>: > > > > On Sat, Sep 25, 2010 at 9:02 PM, StÃ©phane Ducasse <<stephane.ducasse(a)inria.fr> > stephane.ducasse(a)inria.fr> wrote: > >> >> On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote: >> >> > Hi. I am having a probem with Glorp and I really have no idea what can >> be. The problem is that I load the package Glorp and just after loading, I >> do a "changes" in the MC Browser and I see a lot of classes with a lot of >> changes and all of them like "revison changed". This is annoying since it >> doesn't let me easily see what I have really changed. >> > >> > To reproduce: >> > >> > - Load the package "Glorp" from <http://www.squeaksource.com/SqueakDBX> >> http://www.squeaksource.com/SqueakDBX >> > - Open a MC Browser, select Glorp package and press the "Changes" button >> agains the ss repo. And you will see :) >> >> May be the image used to save the package got a problem and changed the >> timestamp of the methods. >> So when you merge you get changed methods. >> > > I've just tried commiting and load them in a clean image...same problem. > > And if it were what you say...is there a solution? > > thanks > > mariano > > >> >> > >> > Any help is really appreaciated. >> > >> > Thanks >> > >> > Mariano >> > _______________________________________________ >> > Pharo-project mailing list >> > <Pharo-project(a)lists.gforge.inria.fr> >> Pharo-project(a)lists.gforge.inria.fr >> > <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> <Pharo-project(a)lists.gforge.inria.fr>Pharo-project(a)lists.gforge.inria.fr >> <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project> >> 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 > -- Javier PimÃ¡s Ciudad de Buenos Aires

Sept. 26, 2010

Re: [Pharo-project] After loading a package...all changes with "revision changed"

by Norbert Hartl

FYI I encountered the same problem in gemstone. The only thing I know is that all loaded packages were created in pharo that showed this behaviour. It didn't show up in a reproducable manner and some packages were clean again after a few package updates. And for some month now I didn't see it. Norbert Am 25.09.2010 um 21:12 schrieb Mariano Martinez Peck <marianopeck(a)gmail.com >: > > > On Sat, Sep 25, 2010 at 9:02 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.f > r> wrote: > > On Sep 25, 2010, at 8:25 PM, Mariano Martinez Peck wrote: > > > Hi. I am having a probem with Glorp and I really have no idea what > can be. The problem is that I load the package Glorp and just after > loading, I do a "changes" in the MC Browser and I see a lot of > classes with a lot of changes and all of them like "revison > changed". This is annoying since it doesn't let me easily see what I > have really changed. > > > > To reproduce: > > > > - Load the package "Glorp" from http://www.squeaksource.com/ > SqueakDBX > > - Open a MC Browser, select Glorp package and press the "Changes" > button agains the ss repo. And you will see :) > > May be the image used to save the package got a problem and changed > the timestamp of the methods. > So when you merge you get changed methods. > > I've just tried commiting and load them in a clean image...same > problem. > > And if it were what you say...is there a solution? > > thanks > > mariano > > > > > > Any help is really appreaciated. > > > > Thanks > > > > Mariano > > _______________________________________________ > > 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

Sept. 26, 2010

Re: [Pharo-project] In Smalltalk you can't loose code... hum

by George Herolyants

2010/9/26 FranÃ§ois Tanguy <francois.tanguy(a)gmail.com>: > Here is what I did: > 1) Open a workspace / save the image > 2) edit the workspace / save Cmd + S > 3) quit Pharo without saving > 4) Open pharo -> the workspace is empty Of course :) You discarded the state of all the objects you created or modified during your Pharo session. There is no object representing workspace anymore. The same result will be if you add some method to some class, after image restart (without saving) there will be no such method. In this case you can use Recover Lost Changes tool to restore your method from .changes file. But in case of workspace you should *explicitely* save it into a file (using a window menu). And after image restart you will be able to restore it from that file.

Sept. 26, 2010

Re: [Pharo-project] NativeBoost opportunties?

by Igor Stasenko

On 26 September 2010 06:43, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Today, I ran into a bug of mine that I would not have had to track down if the various typed byte arrays (double in particular) existed. Â The more you can offer in that area, with indexing, bulk fill, bulk copy, etc., the better. > > I also ran into what appears to be a maximum number of arguments to an external call. Â Can you get around that? Â I can too, in this case. Â It's shameless, but I will "dumb down" the call so that FFI can handle it. Â There are arguments that I can default or provide from a shared library, and just call into a facade function exported from there. Â Shouldn't have to do that, clearly, but it will work. > NB supports facade calls. And i'm using them a lot, since many functions having default values, which never change. There's one limitation, that constant arguments should be 32-bit int/uint. In function spec you can put integer constants or class/pool variables. Suppose you have a C function foo( int x , int y) so, FFI allows you to use only in this style: fooX: x y: y <primitive ... > ^ NBFFICallout cdecl: #( foo (int x, int y) ) module: 'bar' i.e. , method arguments 1:1 matching function argument. With NB, however you can pass them in arbitraty order, or push same argument twice, like: fooX: x <primitive ... > ^ NBFFICallout cdecl: #( foo (int x, byte x) ) module: 'bar' or use constants: fooX: x <primitive ... > ^ NBFFICallout cdecl: #( foo (int x, 0 ) ) module: 'bar' so, y argument will be zero. or use class/pool vars for constants: fooX: x <primitive ... > ^ NBFFICallout cdecl: #( foo (int x, SomeClassVar ) ) module: 'bar' so, it will use a SomeClassVar value at the moment of code generation. or use inst vars as arguments: Point>>foo <primitive ... > ^ NBFFICallout cdecl: #( foo (int x, int y) ) module: 'bar' it will use receiver's x and y instance variables to coerce&push them as arguments. You also can use self (receiver) as an argument name, but then, obviously you have to tell NB how to coerce instance of your class to some C type. > Bill > > > > > _______________________________________________ > 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.

Sept. 26, 2010

[Pharo-project] NativeBoost opportunties?

by Schwab,Wilhelm K

Sig, Today, I ran into a bug of mine that I would not have had to track down if the various typed byte arrays (double in particular) existed. The more you can offer in that area, with indexing, bulk fill, bulk copy, etc., the better. I also ran into what appears to be a maximum number of arguments to an external call. Can you get around that? I can too, in this case. It's shameless, but I will "dumb down" the call so that FFI can handle it. There are arguments that I can default or provide from a shared library, and just call into a facade function exported from there. Shouldn't have to do that, clearly, but it will work. Bill

Sept. 26, 2010

Re: [Pharo-project] [Vm-dev] VM Maker: VMMaker-oscog.33.mcz

by Eliot Miranda

I would appreciate anyone interested in objects-as-methods on Cog pounding on the latest Cog VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2313/) as this involved substantial changes to method lookup/inline cacheing machinery and there could easily be bugs. The tests run, but they're insubstantial compared e.g. to a full coverage test. best Eliot (repeat with fixed email address: squeakfountation => squeakfoundation) On Sat, Sep 25, 2010 at 9:20 PM, < squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://www.squeaksource.com/VMMaker/VMMaker-oscog.33.mcz > > ==================== Summary ==================== > > Name: VMMaker-oscog.33 > Author: eem > Time: 25 September 2010, 7:13:51 am > UUID: 733b7c50-b973-4ca0-9831-5c84d09032bf > Ancestors: VMMaker-oscog.32 > > OSCogVM: > Support object-as-method: > Eagerly evaluate the interpreter version of a primitive > to ease the object-as-method implementation and to > improve interpreter performance. > Refuse to enter anything that isn't a CompiledMethod > into the method-lookup cache to avoid open PICs having > to check for valid compiled methods. > Have various places check for isOopCOmpiledMethod: > rather than isCompiledMethod: to allow SmallIntegers to > be used as methods. > Interpreter: > Have various places check for isOopCOmpiledMethod: > rather than isCompiledMethod: to allow SmallIntegers to > be used as methods. > Slang: > support super sends by expanding them at translation > time. This allows CoInterpreter>>addMethodToCache > to avoid cacheing non-compiled methods via a super > send, avoiding duplicating SrackInterpreter's method. > >

Sept. 26, 2010

Re: [Pharo-project] [Vm-dev] VM Maker: VMMaker-oscog.33.mcz

by Eliot Miranda

I would appreciate anyone interested in objects-as-methods on Cog pounding on the latest Cog VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2313/) as this involved substantial changes to method lookup/inline cacheing machinery and there could easily be bugs. The tests run, but they're insubstantial compared e.g. to a full coverage test. best Eliot On Sat, Sep 25, 2010 at 9:20 PM, < squeak-dev-noreply(a)lists.squeakfoundation.org> wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://www.squeaksource.com/VMMaker/VMMaker-oscog.33.mcz > > ==================== Summary ==================== > > Name: VMMaker-oscog.33 > Author: eem > Time: 25 September 2010, 7:13:51 am > UUID: 733b7c50-b973-4ca0-9831-5c84d09032bf > Ancestors: VMMaker-oscog.32 > > OSCogVM: > Support object-as-method: > Eagerly evaluate the interpreter version of a primitive > to ease the object-as-method implementation and to > improve interpreter performance. > Refuse to enter anything that isn't a CompiledMethod > into the method-lookup cache to avoid open PICs having > to check for valid compiled methods. > Have various places check for isOopCOmpiledMethod: > rather than isCompiledMethod: to allow SmallIntegers to > be used as methods. > Interpreter: > Have various places check for isOopCOmpiledMethod: > rather than isCompiledMethod: to allow SmallIntegers to > be used as methods. > Slang: > support super sends by expanding them at translation > time. This allows CoInterpreter>>addMethodToCache > to avoid cacheing non-compiled methods via a super > send, avoiding duplicating SrackInterpreter's method. > >

Sept. 26, 2010