- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About inline: and var: varSymbol declareC: declString

by Alexandre Bergel

> I imagine > that these > two methods are handy when you want to debug a primitive in Squeak > before generating C code. Not really actually. These methods are used by the translator to put the proper cast (else everything appear as 'int' and the C compiler emits warning when you do operation not suitable for int), and to inline methods (for performance reason). I am not expert in compilation, but I would expect a good C compiler to infer whether a method may be inlined or not. Is this inline: directive still necessary? Ideally, these should be set as pragmas I guess. Alexandre > > > Stef > On Dec 24, 2008, at 2:10 PM, Alexandre Bergel wrote: > >> Adding 'Beeper beep' in the body of these two empty methods does not >> produce any sound. This is normal since methods that use these >> methods >> are primitive. Now, we could remove these two methods from Object, >> but >> it would be wise to leave the calls in the body of primitive methods. >> >> Could be a good example for aspects by the way. >> >> Alexandre >> >> >> On 23 Dec 2008, at 19:20, StÃ©phane Ducasse wrote: >> >>> Hi >>> >>> I'm trying to learn something while reading Object methods. >>> I was wondering whether >>> var: varSymbol declareC: declString and inline: >>> should not be put as Object extension in VMMaker instead of been >>> kept >>> in Object. >>> Now I saw that these methods have senders in the image. >>> Does it mean that part of the code of these senders can be executed >>> when we consider that these two methods are doing nothing? >>> This could be used to debug the code before generating C from it. >>> are my hypotheses correct? >>> >>> Stef >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Alexandre Bergel

I agree with you Keith. As you pointed out, redefining compilerClass should allow you to relax the rules we are talking about. Alexandre On 24 Dec 2008, at 08:30, Keith Hodges wrote: > Michael Rueger wrote: >> On Wed, Dec 24, 2008 at 10:58 AM, <bryce(a)kampjes.demon.co.uk> wrote: >> >> >>> This is a language design point. Is the convenience of knowing that >>> an argument is never modified worth more than the convenience of >>> being >>> able to modify the argument? >>> >> >> What really is the convenience of modifying an argument? Having not >> to >> >> Breaking the kind of conventions makes you think harder about what >> code does and that distracts you from what you really trying to do. >> Or >> should be doing ;-) >> > But you are not getting it. The point is about context. In the context > of smalltalk the conventions make sense. BUT the whole point being > there > are other contexts even within the same environment. > > Sake/Packages uses a smalllalk class as a database of package > definitions, this is another context. My Mantis package uses a class > to > document fixes this is another context. > > Class returns #compilerClass, this means it is possible to put a > different compiler in there. Therefore it is expected that there be > different contexts within the one environment. > > I am not saying that the smalltalk conventions are bad, what I am > saying > is that the flexibility to break the conventions is useful in OTHER > CONTEXTS, and in many ways makes it possible to have other use cases > in > the first place. > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Alexandre Bergel

+ 1 Alexandre On 24 Dec 2008, at 07:11, Michael Rueger wrote: > On Wed, Dec 24, 2008 at 10:58 AM, <bryce(a)kampjes.demon.co.uk> wrote: > >> This is a language design point. Is the convenience of knowing that >> an argument is never modified worth more than the convenience of >> being >> able to modify the argument? > > What really is the convenience of modifying an argument? Having not to > think up another name? I never understood this argument especially if > you need to use the original value of the argument in several places. > > IMHO it is all about how much mental load reading code imposes (the > readability Stephane mentioned). > > If we allow modification of arguments, then I can't just look at code > and "know" that the argument has the value it was passed. > > Same with shadowed variables, a truly horrible idea. I look at code > and see an inst var, but fail to notice it is also an argument or > method var and I'm off being confused about what the code does. > > Same for upper/lowercase conventions, let alone uppercase method > names. > > Breaking the kind of conventions makes you think harder about what > code does and that distracts you from what you really trying to do. Or > should be doing ;-) > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Alexandre Bergel

I do not think that a preference should relax some static language enforcements. Contrary to Java, the Smalltalk community does not appear to be big enough to have these problem unsolvable. I agree with Stephane, having a name that begins with a capitalized letter has a strong connotation of global visibility. And, on the contrary, an identifier beginning with a small letter has a restricted scope. Forbidding a new value to be assigned to a method variable is a simple increase the readability. Even if closure were supported, we should not allow a single identifier to appear as argument in different blocks in the same method. This does not help readability. As a follower to that line, something that would be great to have, is to forbid accesses to an undefined variable. I am aware that I am talking as someone who does not maintain cross- dialect applications, but we cannot trade readability for a local in time commodity. Alexandre On 23 Dec 2008, at 18:02, StÃ©phane Ducasse wrote: > lukas > > would a preference help? > > Stef > > On Dec 23, 2008, at 3:41 PM, Lukas Renggli wrote: > >> Seaside depends on external packages, that we don't have control >> over. >> >> For example there the Swazoo package contains a class-instance >> variable that is uppercase. Unfortunately Pharo throws a notification >> (instance variables should begin with a lower case characters) when >> loading that code. This is awkward, because it makes it impossible to >> load code automatically and gives us additional work. >> >> In my opinion a programming language should be as open as possible, >> and if possible not restrict the user in any way, even if this is >> against best practices. Unfortunately many of those restrictions are >> built into our language that wouldn't be necessary: >> >> - class names and class-variable names are enforced to be uppercase >> - class instance-variable names are enforced to be lowercase >> - it is not possible to assign a new value to a method argument >> - variable names are enforced to be unique in all scopes >> >> In my opinion the language should be as open as possible. It is the >> purpose of Code Critics to point out smells, not the task of the >> compiler to reject code that doesn't follow best practices. >> >> I am slightly frustrated trying to work around these restrictions ... >> >> Cheers, >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Keith Hodges

Michael Rueger wrote: > On Wed, Dec 24, 2008 at 12:30 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote: > > > >> I am not saying that the smalltalk conventions are bad, what I am saying >> is that the flexibility to break the conventions is useful in OTHER >> CONTEXTS, and in many ways makes it possible to have other use cases in >> the first place. >> > > Then break them in the other contexts, but not for the whole system. > > If you allow abuse of the language, people will do it. > But what is the Language? Smalltalk is objects and message sends thats all (at least thats the theory). Whenever this simplicity is compromised then there are problems down the road (e.g. inlining ifTrue:ifFalse: limits the ability to change its behavior and people find a need to diable this inlining) No conventions need to be hard wired. Its the same debate as static vs dynamic typing all over again. Keith

Dec. 24, 2008

Re: [Pharo-project] Gepetto2 and Pharo

by StÃ©phane Ducasse

Ok I thought I saw an BS packagein the repo On Dec 24, 2008, at 2:14 PM, Alexandre Bergel wrote: > I am not sure about what Christo needs exactly. When I load Christo, > Gepetto2 is loaded. I therefore assume that the former needs the > latter. > > Alexandre > > On 23 Dec 2008, at 19:07, StÃ©phane Ducasse wrote: > >> Marcus >> >> You were talking about reflectivity but alex about bytesurgeon. >> Is geppetto2 = reflectivity? >> I thought that christo was based on bytesurgeon and not reflectivity >> >> The paper we want to write is for the 15 of January and alex is >> trying >> to get >> christo running again. >> >> Stef >> >> On Dec 23, 2008, at 11:02 PM, Marcus Denker wrote: >> >>> Hi, >>> >>> I tried to build a Reflectivity image last week using the lastest >>> Pharo and there where strange problems... >>> I did not look closely, I have no idea what they are... I will check >>> later (maybe after christmas). >>> >>> Marcus >>> >>> On Tue, Dec 23, 2008 at 9:17 PM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr >>>> wrote: >>> Hi Marcus, >>> >>> When I run in Pharo the 133 tests of Gepetto2, I have 119 passes, 6 >>> expected failures, 2 failures, and 6 errors. >>> Is there something in Pharo that would prevent Gepetto2 from running >>> correctly ? >>> >>> Alexandre >>> >>> >>> On 23 Dec 2008, at 15:31, Alexandre Bergel wrote: >>> >>>> Hi Marcus, >>>> >>>> Do you know whether Gepetto2 is know to work on Pharo? I am trying >>>> to make Christo (the code coverage tool) run on Pharo. >>>> >>>> (I ask for it publicly since someone else than Marcus may know). >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>>> >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> >>> -- >>> >>> Marcus Denker -- denker(a)iam.unibe.ch >>> http://www.iam.unibe.ch/~denker >>> >>> >>> _______________________________________________ >>> 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 >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2008

Re: [Pharo-project] About inline: and var: varSymbol declareC: declString

by StÃ©phane Ducasse

I will wait that somebody with VM building knowledge reply. I imagine that these two methods are handy when you want to debug a primitive in Squeak before generating C code. Stef On Dec 24, 2008, at 2:10 PM, Alexandre Bergel wrote: > Adding 'Beeper beep' in the body of these two empty methods does not > produce any sound. This is normal since methods that use these methods > are primitive. Now, we could remove these two methods from Object, but > it would be wise to leave the calls in the body of primitive methods. > > Could be a good example for aspects by the way. > > Alexandre > > > On 23 Dec 2008, at 19:20, StÃ©phane Ducasse wrote: > >> Hi >> >> I'm trying to learn something while reading Object methods. >> I was wondering whether >> var: varSymbol declareC: declString and inline: >> should not be put as Object extension in VMMaker instead of been >> kept >> in Object. >> Now I saw that these methods have senders in the image. >> Does it mean that part of the code of these senders can be executed >> when we consider that these two methods are doing nothing? >> This could be used to debug the code before generating C from it. >> are my hypotheses correct? >> >> Stef >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2008

Re: [Pharo-project] A design question

by StÃ©phane Ducasse

yes but so far none of the moprh class specialised this method. On Dec 24, 2008, at 2:00 PM, Alexandre Bergel wrote: > It depends whether it makes sense or not to have a different threshold > for objects. > Maybe an expert in gui may help to answer this... > > Alexandre > > > On 23 Dec 2008, at 19:19, StÃ©phane Ducasse wrote: > >> Hi >> >> I would like to get your point of view on the following: >> In Object there is the method >> >> updateThresholdForGraphicInViewerTab >> "When a Viewer is open on the receiver, its tab needs some graphic >> to >> show to the user. Computing this graphic can take quite some time so >> we want to make the update frequency depending on how long it takes >> to >> compute the thumbnail. The threshold returned by this method defines >> that the viewer will update at most every 'threshold * >> timeItTakesToDraw' milliseconds. Thus, if the time for computing the >> receiver's thumbnail is 200 msecs and the the threshold is 10, the >> viewer will update at most every two seconds." >> ^20 "seems to be a pretty good general choice" >> >> which is only defined on Object. >> and only called by >> >> ThumbnailMorph>>stepTime >> "Adjust my step time to the time it takes drawing my referent" >> drawTime ifNil:[^ 250]. >> ^(objectToView updateThresholdForGraphicInViewerTab * drawTime) max: >> 250. >> >> and I was thinking ok this a nice hook and may be it should be a >> morphic extension on >> Object. On the other hand it seems that this is a feature that is >> only >> use by one class >> that is not even core. So may be we could put the magic number inside >> the step time. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 24, 2008

Re: [Pharo-project] Gepetto2 and Pharo

by Alexandre Bergel

I am not sure about what Christo needs exactly. When I load Christo, Gepetto2 is loaded. I therefore assume that the former needs the latter. Alexandre On 23 Dec 2008, at 19:07, StÃ©phane Ducasse wrote: > Marcus > > You were talking about reflectivity but alex about bytesurgeon. > Is geppetto2 = reflectivity? > I thought that christo was based on bytesurgeon and not reflectivity > > The paper we want to write is for the 15 of January and alex is trying > to get > christo running again. > > Stef > > On Dec 23, 2008, at 11:02 PM, Marcus Denker wrote: > >> Hi, >> >> I tried to build a Reflectivity image last week using the lastest >> Pharo and there where strange problems... >> I did not look closely, I have no idea what they are... I will check >> later (maybe after christmas). >> >> Marcus >> >> On Tue, Dec 23, 2008 at 9:17 PM, Alexandre Bergel <Alexandre.Bergel(a)inria.fr >>> wrote: >> Hi Marcus, >> >> When I run in Pharo the 133 tests of Gepetto2, I have 119 passes, 6 >> expected failures, 2 failures, and 6 errors. >> Is there something in Pharo that would prevent Gepetto2 from running >> correctly ? >> >> Alexandre >> >> >> On 23 Dec 2008, at 15:31, Alexandre Bergel wrote: >> >>> Hi Marcus, >>> >>> Do you know whether Gepetto2 is know to work on Pharo? I am trying >>> to make Christo (the code coverage tool) run on Pharo. >>> >>> (I ask for it publicly since someone else than Marcus may know). >>> >>> Cheers, >>> Alexandre >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> 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 > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2008

Re: [Pharo-project] About inline: and var: varSymbol declareC: declString

by Alexandre Bergel

Adding 'Beeper beep' in the body of these two empty methods does not produce any sound. This is normal since methods that use these methods are primitive. Now, we could remove these two methods from Object, but it would be wise to leave the calls in the body of primitive methods. Could be a good example for aspects by the way. Alexandre On 23 Dec 2008, at 19:20, StÃ©phane Ducasse wrote: > Hi > > I'm trying to learn something while reading Object methods. > I was wondering whether > var: varSymbol declareC: declString and inline: > should not be put as Object extension in VMMaker instead of been kept > in Object. > Now I saw that these methods have senders in the image. > Does it mean that part of the code of these senders can be executed > when we consider that these two methods are doing nothing? > This could be used to debug the code before generating C from it. > are my hypotheses correct? > > Stef > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 24, 2008