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

Re: [Pharo-project] Alien Plugin for Linux

by Alberto Bacchelli

On 9/27/10 8:13 PM, Eliot Miranda wrote: > > > 2010/9/27 Fernando olivero<fernando.olivero(a)usi.ch<mailto:fernando.olivero@usi.ch>> > Does the prebuilt CogVM for linux include Alien support? > http://www.mirandabanda.org/files/Cog/VM/VM.r2313/ > > Only of the data manipulation and callout parts, not the callback parts. I'm trying to find time to work on integrating the Alien callback machinery with the FFI. > > best > Eliot We had a problem after installing Alien, when running the tests. The following does not understand MessageNotUnderstood: Array>>createMethod:header:methodClass: sent by CompileMethod class>>newBytes:trailerBytes:nArgs:nTemps:nStack:nLits:primitive: It appears to be cog related, is it? Thank you, Alberto

Sept. 28, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by StÃ©phane Ducasse

indeed. > Perhaps interestingly, in the original Self paper promoting mirrors, > it was argued that one of the lessons learned of using mirrors in self > was that '==' is really a reflective property, that should be > accessible only through mirrors. That is because, whether or not two > pointers are equal is really a question on the VM level, and not on > your business level. > > Niko

Sept. 28, 2010

Re: [Pharo-project] Feature request for Opal

by StÃ©phane Ducasse

> What you ask for was present in my original pragma implementation. The > compiler dispatched pragmas that were declared as compiler pragmas > (using pragmas and thus extensible) to the compiler. as it should be done. Nice music to my hears. > > That mechanism got lost with the closure changes to the compiler. It > should be relatively easy to re-integrate again. > > I never bother to do so, because the mechanism was never adopted by > the only potential client at that time as the author didn't like > pragmas and preferred to patch the compiler :-) May be jealous not to have invented it? ;-) Stef

Sept. 28, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Niko Schwarz

But that's the point, there should be no business semantics to '=='. Only reflective semantics. The reflective semantics are ok. Niko On Mon, Sep 27, 2010 at 11:51 AM, Johan Brichau <johan(a)inceptive.be> wrote: > > On 27 Sep 2010, at 11:28, Igor Stasenko wrote: > >> On 27 September 2010 11:54, Johan Brichau <johan(a)inceptive.be> wrote: >>> >>> On 27 Sep 2010, at 10:38, Lukas Renggli wrote: >>> >>>>> Am I wrong? >>>> >>>> Yes, almost always one should probably use #= instead of #==. >>> >>> I will add that to the exercise :-) >>> The exercise actually makes students aware of the difference between strings and symbols (which should be pointer-equal) >>> >> >> I think you can avoid using 'equal' word when describing a #== comparison. >> It can be explained as 'test whether comparands are same object or not' >> while #= is test whether two objects equal or not. > > Yes, this is exactly what the exercise is doing. > I want them to be aware that equal _symbols_ are the same objects, but that equal _strings_ are not, which is why I let them evaluate: > > a := #foobar. > b := #foobar. > a == b. > > a := 'foobar'. > b := 'foobar'. > a == b > > The problem is that evaluating the second snippet also yields true in Pharo/Squeak, so I cannot illustrate it using these snippets (which works fine in Visualworks, btw). > > Yes, this is a compiler optimization and, yes, people should use #= instead of #== normally. But imho the optimization yields a wrong semantics, which is why I posted the email. > > I have absolutely no clue if it can be changed (I am not familiar with the compiler implementation *at all*), but I would be happy to look over the shoulder of an experienced compiler hacker during the next sprint to learn ;-) > > cheers > Johan > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Sept. 28, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by Niko Schwarz

Perhaps interestingly, in the original Self paper promoting mirrors, it was argued that one of the lessons learned of using mirrors in self was that '==' is really a reflective property, that should be accessible only through mirrors. That is because, whether or not two pointers are equal is really a question on the VM level, and not on your business level. Niko On Mon, Sep 27, 2010 at 10:32 AM, Johan Brichau <johan(a)inceptive.be> wrote: > I convinced the teacher who will be taking over my Smalltalk courses at UCLouvain (starting this week) to use Pharo :-) > One of the introductory exercises in these courses shows the difference between '==' and '='. However, in Pharo (&Squeak) the following goes wrong imho: > > 'a' == 'a' -> true > $a asString == $a asString -> false > > It seems that when you evaluate the expression, the (semantically identical) strings are represented as the same literal in the compiled block. > For example, try to evaluate the following code by evaluating each statement in a separate doit. Then do it again as a single block... > > |a b| > a := 'a'. > b := 'a'. > a == b inspect > > > Do I make it an issue? Is there already an issue? (did not find one) > Am I wrong? > > Johan > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683

Sept. 28, 2010

Re: [Pharo-project] Feature request for Opal

by Lukas Renggli

What you ask for was present in my original pragma implementation. The compiler dispatched pragmas that were declared as compiler pragmas (using pragmas and thus extensible) to the compiler. That mechanism got lost with the closure changes to the compiler. It should be relatively easy to re-integrate again. I never bother to do so, because the mechanism was never adopted by the only potential client at that time as the author didn't like pragmas and preferred to patch the compiler :-) Lukas -- Lukas Renggli www.lukas-renggli.ch

Sept. 28, 2010

[Pharo-project] Feature request for Opal

by Igor Stasenko

I want an API for easy plugging in an arbitrary pragma handler, which could then either completely intercept parser/compiler output or modify output. This is userful for things like clean implementation of FFI pragmas, without patching the Parser as well as for scenarios like: myMethod: myArg <myLanguage> foo|<bar**baz so, once pragma <myLanguage> parsed, and handled, an input source stream redirected to completely different parser/compier pair which, of course, should produce a compiled method as a result, but may use any syntax. -- Best regards, Igor Stasenko AKA sig.

Sept. 28, 2010

Re: [Pharo-project] ('a' == 'a') == true ?

by StÃ©phane Ducasse

+1 > Well, you can save a bit more, if you scan a whole image literals and > unify them. > This could be userful for tidying up the image size. > > > Probably yes, but that's not the point I guess. I just wanted to show that the current method doesn't really save much. Unifying the literals in the image is dangerous, because literal strings are not immutable (and they shouldn't be IMHO). + 10 I would love to have immutability bit. > So that could lead to random errors if a method is modifying a shared string literal. This can of aliasing is bad, it mixes semantics and implementation. I hope that we will be able to fix that with Opal. Stef

Sept. 28, 2010

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

by StÃ©phane Ducasse

it would be nice to have a simple case that we can reproduce. Stef On Sep 27, 2010, at 10:42 PM, Mariano Martinez Peck wrote: > > > 2010/9/26 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > 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. > > > Thanks. It is good to know I am not the only one. This bug is REAAAAALY annoying since you cannot see your changes. > > I've checked and I have no #initialize at class level :( > > The only thing I found is class side #new implementd something like: > > new > > ^super new initialize. > > can this be the problem? > > where could I put a halt to see the problem ? > > thanks in advance > > mariano > > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 28, 2010

[Pharo-project] Pharocasts new url

by laurent laffont

Now on http://www.pharocasts.com/ Laurent Laffont http://www.pharocasts.com/ http://magaloma.blogspot.com/

Sept. 28, 2010