- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3792 in pharo: PluggableListMorph with a wrapper for display

by pharo＠googlecode.com

Status: Fixed Owner: Benjamin...(a)gmail.com New issue 3792 by Benjamin...(a)gmail.com: PluggableListMorph with a wrapper for display http://code.google.com/p/pharo/issues/detail?id=3792 I now provide a way (or maybe Alain will said it already exists ^^) to change the way item are displayed using the method wrapSelector: aSymbol where aSymbol is the name of a one argument method. That way, you can store real Object (not Strings), and change the way items are displayed ============================================================= Example: buildList list := PluggableListMorph on: self list: #getList selected: #selected changeSelected: #selected:. list wrapSelector: #listWrapper:. ^ list where: listWrapper: anElement ^ anElement name Here anElement is the raw item from the list. Attachments: PluggableListMorphWithWrapper.2.cs 2.2 KB

March 8, 2011

Re: [Pharo-project] Issue 3791 in pharo: fit all windows to be visible

by pharo＠googlecode.com

Comment #2 on issue 3791 by Benjamin...(a)gmail.com: fit all windows to be visible http://code.google.com/p/pharo/issues/detail?id=3791 Name: SLICE-Issue-3791-fit-all-windows-to-be-visible-janniklaval.1 Author: janniklaval Time: 8 March 2011, 12:37:43 pm UUID: b07154a3-d527-4bc3-97a8-7c955ce7d629 Ancestors: Dependencies: Morphic-janniklaval.832 In PharoInbox

March 8, 2011

Re: [Pharo-project] Issue 3791 in pharo: fit all windows to be visible

by pharo＠googlecode.com

Comment #1 on issue 3791 by stephane...(a)gmail.com: fit all windows to be visible http://code.google.com/p/pharo/issues/detail?id=3791 where is the code?

March 8, 2011

Re: [Pharo-project] [Vm-dev] changing the bytecodes print

by Tobias Pape

Am 2011-03-08 um 09:06 schrieb Mariano Martinez Peck: > Hi folks. Did you see that when you see the bytecodes of a method you see something like: > > 49 <70> self > 50 <21> pushConstant: 'SQ_HOST32' > 51 <8F 00 00 02> closureNumCopied: 0 numArgs: 0 bytes 55 to 56 > 55 <71> pushConstant: true > 56 <7D> blockReturn > ....... > > > The bytecode number here is printed in <hex> . However, in Interpreter and its #initializeBytecodeTable they use base 10. So, each time I read a bytecode, and I want to know which is the method associated with that, I need to convert it. > So, I wonder if it makes sense to change the print, so that it prints in decimal. What do you think? > > To change that, it seems to be in InstructionPrinter >> #print but I cannot make it work yet :( I can understand your urge, but be aware that a Hex number in the bytecode range always takes up (at max) two characters (as in 00 â FF). Probably, using hex numbers ind the #initializeBytecodeTable would be the better idea? So Long, -Tobias

March 8, 2011

[Pharo-project] Issue 3791 in pharo: fit all windows to be visible

by pharo＠googlecode.com

Status: FixProposed Owner: jannik.l...(a)gmail.com New issue 3791 by jannik.l...(a)gmail.com: fit all windows to be visible http://code.google.com/p/pharo/issues/detail?id=3791 when we resize in small the Pharo window, all windows keep there size. I added a command to place and resize windows to be visible and accessible when we resize Pharo window. This command is available in WorldMenu/Windows/Fit all windows

March 8, 2011

Re: [Pharo-project] About the sprint saturday 12

by Gary Chambers

No, for the Bern sprint. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, March 07, 2011 8:11 PM Subject: Re: [Pharo-project] About the sprint saturday 12 you mean for the 12? Stef On Mar 7, 2011, at 5:40 PM, Gary Chambers wrote: > As indicated, due to lack of response prior to event I scheduled other > activities, unfortunately... > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" > <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, March 07, 2011 4:26 PM > Subject: Re: [Pharo-project] About the sprint saturday 12 > > > did you try screen sharing? > > On Mar 7, 2011, at 5:25 PM, Gary Chambers wrote: > >> Indeed, I'll be on email/IRC#pharo or whatever else is needed then. >> >> Regards, Gary >> >> ----- Original Message ----- From: "StÃ©phane Ducasse" >> <stephane.ducasse(a)inria.fr> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Monday, March 07, 2011 4:05 PM >> Subject: Re: [Pharo-project] About the sprint saturday 12 >> >> >> Good. >> I would like to merge all the polymorph overrides :). >> With alain we are building a roadmap to move the UI. >> >> Stef >> >> >>> As before I 'can' be available on IRC if interested... >>> Book now, as with the Bern sprint I had no reply... >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "StÃ©phane Ducasse" >>> <stephane.ducasse(a)inria.fr> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Monday, March 07, 2011 3:09 PM >>> Subject: Re: [Pharo-project] About the sprint saturday 12 >>> >>> >>> 9 in the morning until 17h >>> INRIA is 15 min by tram from the station direct connection. >>> >>> Stef >>> >>> On Mar 7, 2011, at 3:15 PM, Francois Stephany wrote: >>> >>>> Hi, >>>> >>>> At what time do you start/finish ? Is it far from Lille train station ? >>>> >>>> Cheers, >>>> Francois >>>> >>>> On 03/03/11 17:30, StÃ©phane Ducasse wrote: >>>>> Hi guys and participants of the school, >>>>> >>>>> we proposed to organize a spring saturday 12 so that you can get >>>>> involved and get the feel >>>>> of a fun coding party. Now we need to know if you plan to participate >>>>> so that we >>>>> can reserve a room and prepare something for lunch. >>>>> >>>>> So could you reply to this email so that we know what we should >>>>> prepare. >>>>> >>>>> Stef >>>> >>> >>> >>> >> >> >> > > >

March 8, 2011

Re: [Pharo-project] Hardware cursor vs Software Cursor

by Henrik Johansen

On Mar 8, 2011, at 11:00 21AM, Fernando Olivero wrote: > I believe that the senders or Cursor xxx showWhile: .. are using the > wrong level of abstraction, > by directly referring to the Cursor class reference > and more important, that all visual related cues must go thru UIManager . > > If we take this approach further, we see there's > 1) no need to have a special Cursor class. > 2) We can remove the Hardware cursors and the software cursor > distinction, so any Form can be used as a "cursor" image. Leading to > an understandable implementation of the drawing behind HandMorph ( if > not convinced try out " Cursor wait show" , and see that nothing > happens) > > Solution: > *Refactor HandMorph, removing the distinction between hardware and > software cursor. > *Make the Cursor senders, to use the proper level of abstraction ( > not directly using the hardware cursor, such as Cursor wait > showWhile:[..]) > *Remove Cursor. > > > I will work on this, and once create an issue once working. > > Saludos, > Fernando > For an interesting view of showWhile:, read http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&… Cheers, Henry

March 8, 2011

[Pharo-project] Hardware cursor vs Software Cursor

by Fernando Olivero

I believe that the senders or Cursor xxx showWhile: .. are using the wrong level of abstraction, by directly referring to the Cursor class reference and more important, that all visual related cues must go thru UIManager . If we take this approach further, we see there's 1) no need to have a special Cursor class. 2) We can remove the Hardware cursors and the software cursor distinction, so any Form can be used as a "cursor" image. Leading to an understandable implementation of the drawing behind HandMorph ( if not convinced try out " Cursor wait show" , and see that nothing happens) Solution: *Refactor HandMorph, removing the distinction between hardware and software cursor. *Make the Cursor senders, to use the proper level of abstraction ( not directly using the hardware cursor, such as Cursor wait showWhile:[..]) *Remove Cursor. I will work on this, and once create an issue once working. Saludos, Fernando

March 8, 2011

Re: [Pharo-project] Pharo on top of Flash plugin

by Marcus Denker

On Mar 7, 2011, at 1:29 PM, Alexandre Jasmin wrote: >>> Your image helps me a lot. >>> >>> I'm trying to get the Squeak VM compiling with Adobe Alchemy. >> >> tell us more :) > > > There are at least two solutions aiming to bring native code to the web > without installing plug-ins > - Google Native Client provides a sandboxed environment for x86 code The interesting aspect of NaCl is that it does have a JIT compiler API... (Mono is using it already). This means, it would be possible to port Cog to NaCl *and* have all the speed... Getting the stack interpreter to run should be even simpler (recompile.. plus implementing I/O via the NaCl APIs , of course). http://blog.chromium.org/2011/02/native-client-getting-ready-for-takeoff.ht… > - Alchemy (a research project at Adobe) compiles C into the bytecode > language interpreted by Flash. > ... > > Will let you know how it goes. Very interesting direction, too! The most challenging question is if it's possible to somehow "JIT" code... and how fast that then can be. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 8, 2011

[Pharo-project] changing the bytecodes print

by Mariano Martinez Peck

Hi folks. Did you see that when you see the bytecodes of a method you see something like: 49 <70> self 50 <21> pushConstant: 'SQ_HOST32' 51 <8F 00 00 02> closureNumCopied: 0 numArgs: 0 bytes 55 to 56 55 <71> pushConstant: true 56 <7D> blockReturn ....... The bytecode number here is printed in <hex> . However, in Interpreter and its #initializeBytecodeTable they use base 10. So, each time I read a bytecode, and I want to know which is the method associated with that, I need to convert it. So, I wonder if it makes sense to change the print, so that it prints in decimal. What do you think? To change that, it seems to be in InstructionPrinter >> #print but I cannot make it work yet :( cheers Mariano

March 8, 2011