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

Re: [Pharo-project] FWd: Mason

by Michael Roberts

Hi, thanks for forwarding. i too was looking for some example code ;-) Mike On Mon, Dec 14, 2009 at 1:08 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > More infos on Mason to automatically build images, > last one with a short example. > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/142088… > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-December/142128…

Dec. 14, 2009

Re: [Pharo-project] Syntax highlighting changed in 10500?

by Simon Denier

On 14 dÃ©c. 2009, at 19:50, Lukas Renggli wrote: > The syntax highlighting should be made a preference with our shiny new > preference framework. > > I don't want any other coloring, I am using that color scheme for over > 15 years now. > > Power to the people! Yep, let's do some preferences for that. How do we start? :) > > Lukas > > 2009/12/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> Can someone attach both screenshots or explain me how to test both ? >> >> Thank you very much. >> >> Mariano >> >> On Mon, Dec 14, 2009 at 1:05 PM, Damien Cassou <damien.cassou(a)gmail.com> >> wrote: >>> >>> On Mon, Dec 14, 2009 at 11:44 AM, Simon Denier <Simon.Denier(a)inria.fr> >>> wrote: >>>> Especially, there is no more color-based discrimination between a class >>>> name, a local variable, a parameter, or an instance variable. I think it is >>>> a regression. >>> >>> I think these are Lukas Renggli's color. We have to choose what colors we >>> want. >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Lambdas are relegated to relative obscurity until Java makes them >>> popular by not having them." James Iry >>> >>> _______________________________________________ >>> 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 >> > > > > -- > 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 -- Simon

Dec. 14, 2009

Re: [Pharo-project] SystemVersion 1.1 Part 2

by Michael Roberts

Hi Marcus, sorry can you try again please Mike

Dec. 14, 2009

Re: [Pharo-project] squeak VM 5.0

by Laval Jannik

Hi John, I see this method: ------------ fixedPlusIndexableSizeFor: object "Return my total number of fields" (object isContextPart) ifTrue: [^ object class instSize + object frameSize]. object isCompiledMethod ifTrue: [^ object basicSize + (self pcDeltaForMethod: object)]. ^ object class instSize + object basicSize ------------- So maybe it needs a line like: ------------- (object class = BlockClosure) ifTrue: [^ object class instSize + (self pcDeltaForMethod: object method)]. ------------- But this one does not work.... Do you have an idea ? Or maybe I am not on the good way. Cheers, Jannik On Dec 7, 2009, at 04:59 , John M McIntosh wrote: > Eliot and I spent 30 minutes chatting about what is wrong. The conclusion is we *think* we are doing the right thing, > yet the Virtual Machine says the image is busted. So a quick fix is not apparent, and we'll dig more. > > On 2009-12-05, at 11:42 PM, John M McIntosh wrote: > >> >> On 2009-12-05, at 9:46 PM, Laval Jannik wrote: >> >>>> I added >>>> object class = BlockClosure ifTrue: >>>> [(object instVarAt: 3) ifNotNil: >>>> ["May need to adjust PC and startPC if changing wordSize..." >>>> results at: 2 put: (block value: (object instVarAt: 2)+(self pcDeltaForMethod: object method) value: 2)]]. >> >> >> Oops should be >> >> object class = BlockClosure ifTrue: >> ["May need to adjust PC and startPC if changing wordSize..." >> results at: 2 put: (block value: (object instVarAt: 2)+(self pcDeltaForMethod: object method) value: 2)]. >> >> Post your current change set so we can see >> >> However that just gives me, which is where I was earlier. >> >> >> <PastedGraphic-2.tiff> > > -- > =========================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > >

Dec. 14, 2009

Re: [Pharo-project] Syntax highlighting changed in 10500?

by csrabak＠bol.com.br

+ 1 Em 14/12/2009 17:32, Tudor Girba <tudor.girba(a)gmail.com> escreveu: Hi, There are two things that I like very much in the previous color scheme. 1. the local variables and the parameters were displayed with gray and instance variables and classes were displayed with black. This had the nice advantage of distinguishing both the classes and the instance variables in one glance. You could argue that this introduces a new visual variable, but the choice of the coloring was actually quite intuitive and with basically no cost: - all variables are shown with shades of gray (thus requiring only one mental mapping), and - the darkness is used to show the "prominence" of a variable: the larger the scope the darker the variable 2. The other nice thing in the previous coloring is the coloring of matching parentheses. This is quite nice when using blocks for scripting. Cheers, Doru

Dec. 14, 2009

Re: [Pharo-project] Syntax highlighting changed in 10500?

by Tudor Girba

Hi, There are two things that I like very much in the previous color scheme. 1. the local variables and the parameters were displayed with gray and instance variables and classes were displayed with black. This had the nice advantage of distinguishing both the classes and the instance variables in one glance. You could argue that this introduces a new visual variable, but the choice of the coloring was actually quite intuitive and with basically no cost: - all variables are shown with shades of gray (thus requiring only one mental mapping), and - the darkness is used to show the "prominence" of a variable: the larger the scope the darker the variable 2. The other nice thing in the previous coloring is the coloring of matching parentheses. This is quite nice when using blocks for scripting. Cheers, Doru On 14 Dec 2009, at 20:11, StÃ©phane Ducasse wrote: > you are getting old :) > > Now distinguish class from variables is nice. > >> The syntax highlighting should be made a preference with our shiny >> new >> preference framework. >> >> I don't want any other coloring, I am using that color scheme for >> over >> 15 years now. >> >> Power to the people! >> >> Lukas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "It's not how it is, it is how we see it."

Dec. 14, 2009

Re: [Pharo-project] Syntax highlighting changed in 10500?

by StÃ©phane Ducasse

you are getting old :) Now distinguish class from variables is nice. > The syntax highlighting should be made a preference with our shiny new > preference framework. > > I don't want any other coloring, I am using that color scheme for over > 15 years now. > > Power to the people! > > Lukas

Dec. 14, 2009

Re: [Pharo-project] Syntax highlighting changed in 10500?

by Lukas Renggli

The syntax highlighting should be made a preference with our shiny new preference framework. I don't want any other coloring, I am using that color scheme for over 15 years now. Power to the people! Lukas 2009/12/14 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Can someone attach both screenshots or explain me how to test both ? > > Thank you very much. > > Mariano > > On Mon, Dec 14, 2009 at 1:05 PM, Damien Cassou <damien.cassou(a)gmail.com> > wrote: >> >> On Mon, Dec 14, 2009 at 11:44 AM, Simon Denier <Simon.Denier(a)inria.fr> >> wrote: >> > Especially, there is no more color-based discrimination between a class >> > name, a local variable, a parameter, or an instance variable. I think it is >> > a regression. >> >> I think these are Lukas Renggli's color. We have to choose what colors we >> want. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> 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 > -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 14, 2009

Re: [Pharo-project] Syntax highlighting changed in 10500?

by Mariano Martinez Peck

Can someone attach both screenshots or explain me how to test both ? Thank you very much. Mariano On Mon, Dec 14, 2009 at 1:05 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > On Mon, Dec 14, 2009 at 11:44 AM, Simon Denier <Simon.Denier(a)inria.fr> > wrote: > > Especially, there is no more color-based discrimination between a class > name, a local variable, a parameter, or an instance variable. I think it is > a regression. > > I think these are Lukas Renggli's color. We have to choose what colors we > want. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 14, 2009

[Pharo-project] Fwd: [squeak-dev] [ANN] CoroutineReadStream (again)

by Mariano Martinez Peck

I didn't understand it too much, but maybe it is worth to check it ? Cheers, Mariano ---------- Forwarded message ---------- From: Stephen Pair <stephen(a)pairhome.net> Date: Mon, Dec 14, 2009 at 2:22 AM Subject: [squeak-dev] [ANN] CoroutineReadStream (again) To: The general-purpose Squeak developers list < squeak-dev(a)lists.squeakfoundation.org> This version fixes a bug in #close that causes the coroutine to not get unwound when the stream is closed. Also, it now uses the stream itself as a marker instead of a special string (a suggestion from Eliot). I've also created unit tests (which is how I caught the problem with close). Below is the class comment: ----- I enable the use of a ReadStream interface in cases where enumeration protocol is available, but no read stream interface is available. For example, I can adapt any object that supports #do: for enumeration: CoroutineReadStream on: #(1 2 3) iterator: #do: The implementation makes use of coroutines to avoid the need to create and schedule a separate Process. Sending #close will abandon the coroutine and unwind all contexts in the coroutine. The coroutine is not invoked until the first request for an object. The iterator is finished when there is an attempt to read past the end (via #next or #peek), or when there is an #atEnd test after the last object was retrieved. A CoroutineReadSteam is not particularly efficient due to its use of thisContext and how stacks are optimized in most Smalltalk implementations. Instance Variables: nextValue <Object | noObjectMarker> Holds the next value to be answered when #next is called (needed to support #peek and #atEnd)...if it holds the noObjectMarker, it inticates that the coroutine needs to be invoked to get the next object. suspendedContext <ContextPart> This is either the context of the iterating stack (when not actively retrieving the next object for a client) or the stack of the user of the stream (when of retrieving the next object) homeContext <MethodContext> Holds the context of #initializeForBlock: called during instantiation and is used to ensure that exception propagation and handling works as one would expect. Copyright (c) 2009 Stephen Pair Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. - Stephen

Dec. 14, 2009