March 2011 - Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] [ANN] ESUG supports once again SqueakDBX

by Alan Knight

As far as the item of updating the Glorp port, that would be great. I note that there is a crude porting tool that generates Squeak fileouts included in Glorp. There is also the work that was done for Seaside that can convert back and forth between a Store database and a Monticello repository. I think that it is not trivial to set up, but since I am the manager of the authors it should be possible to get some help. That would also be nice to then have fixes flowing in both directions. On 2011-03-04 3:40 AM, Mariano Martinez Peck wrote: > We are really happy to announce that ESUG will sponsor us once again > through the ESUG Summer Talk project. This means that we have reached > the ESUG expectations and that they still think that relational > database access is an important matter in Smalltalk. > > One important thing is that we are going to rename the project (we are > still working on it) since SqueakDBX runs not only in Squeak but also > in Pharo, and there have been even ports to Dolphin. What's the reason > for this decision? Because we do not want to couple ourselves to a > smalltalk dialect nor to OpenDBX, because our project is much more > than that (later I will tell you about our plans). So, these are some > of the possible names: ObjectPark, SmallParking, Parktalk, SmallValet, > Valetalk, ValetST, NorayTalk, Ballard, Noray and Cruise. Please let us > know which one is your favourite or help us find a new one. > > Another important subject is the team. There will be three "mentors", > Esteban Lorenzano, Diogenes Moreira and myself, Mariano Martinez Peck; > and three students: Guillermo Polito, Nicolas Scarcella and Santiago > Bragagnolo. > > We are open to suggestions and ideas. In addition, we have defined a > possible list of actions that I copy at the end of the email. > > > For the moment, the url remains www.squeakdbx.org > <http://www.squeakdbx.org/> and the mailing list > squeakdbx(a)lists.squeakfoundation.org > <mailto:squeakdbx@lists.squeakfoundation.org> > > Once again, we want to thank ESUG for their support and trust. > > Thank you very much, > > SqueakDBX team > > > > > > Possible list of actions: > > > 1) Change SqueakDBXâs name. > > 2) Update GLORP version since the actual one is 3 years old. > > Port it again from VisualWorks, create a VW porting tool (may be). > Complete support to Glorp. Today it works with PostgreSQL, Oracle and > MySQL. Make it work with most databases OpenDBX supports. > > 3) Create a lightweight solution, alternatively to GLORP. There are > some options: > > Make SqueakSave work with SqueakDBX. SqueakSave developers already > contacted us because they wanted to do it. SqueakSave seems to be 20% > slower than Glorp but you don't need to write the mappings :) > Adapt Ramon Leon's active record to use an abstract database driver, > and create a driver for SqueakDBX. > Port the new Glorpâs kind of active record to Pharo. (included in 2). > > 4) Write a Pharo By Example 2 chapter based on the card game Stef > built ;). > > 5) Cog compatibility. > > 6) Use Alien instead of FFI. > Eliot is working on a threaded CogVM. One of the projects of the GSoC > of this year was to make something similar to a threaded FFI. What the > student did is a modification in Alien (I think) that can be run in a > multithreaded envirorment. He worked with Eliot. The idea is when > Eliot releases the threaded CogVM, this FFI would work our of the box, > and would avoid locking the WHOLE vm while a C function is being > invoked (as it happens today with FFI).....So....when that VM is > released, we MUST migrate to that). > > 7) Explore performance issues (maybe with our approach of "In thread > execution plugin"). > > 8) Complete integration with OpenDBX. For example, Oracle, for large > objects (Clob, Blob, etc) use specific functions. There are specific > functions in OpenDBX that have to be used if the database uses > specific functions (oracle is the only one for the moment.). We don't > manage those functions yet. > > > 9) In this link http://www.squeakdbx.org/Targets%20and%20Features > You can see a list of future possible features like Connection pooling > (now it is done!), Prepared statement interface, Store procedures, > Escape and avoid of SQL insertion, Authentication support: extends to > other methods, not only user/password, Full text support, etc. -- Alan Knight [|], Engineering Manager, Cincom Smalltalk knight(a)acm.org aknight(a)cincom.com http://www.cincomsmalltalk.com

March 7, 2011

[Pharo-project] [update 1.3] #13076

by StÃ©phane Ducasse

13076 ----- - repackaged MouseWheelEvent - moving AbstractResizerMorph overrides to polymorph extensions

March 7, 2011

[Pharo-project] Seaside305 in Squeak 4.2

by Torsten Bergmann

Original discussion on seaside list (now cc'ing Pharo list too) Phillipe wrote on seaside list: >In general we use the OmniBrowser from [1], but it has issues in Pharo >1.2 as well :-( AFAIK these issues have been addressed and there is a Pharo specific OB version which is now hosted at squeaksource.com/PharoOB.html It is also used to build Pharo 1.2 already. For details ask Guillermo Polito or on Pharo-dev list. Lukas wrote: >I have a nicely working version of OB with RB, Shout and eCompletion >for Pharo 1.2. Just add <http://source.lukas-renggli.ch/pharo12 So you forked again and I wonder why? Thx T. -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

March 7, 2011

Re: [Pharo-project] [Pharo-users] Pharocasts: Build a XML browser

by Tudor Girba

Thanks :). I finally settled on a set of tools that kind of work at the moment, so indeed, more screencasts will come. Cheers, Doru On 7 Mar 2011, at 18:01, laurent laffont wrote: > > On Mon, Mar 7, 2011 at 4:47 PM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > Nice. > > Just for comparison, I created a counter part demo for the browser building part using Glamour: > http://www.tudorgirba.com/blog/simple-xml-browser-with-glamour > > > Cool ! I've updated PharoCasts to link on your demo. (oh, and can't wait your screencasts on Moose ;) > > Laurent. > > > > Cheers, > Doru > > > On 6 Mar 2011, at 22:31, laurent laffont wrote: > >> Watch this to learn how to: >> - get and parse XML >> - use Polymorph to build a GUI with a tree and text editor >> - add a button in Pharo IDE to open the XML browser >> - control when your breakpoints will trigger >> >> see http://www.pharocasts.com/2011/03/build-xml-browser.html >> >> >> Laurent Laffont - @lolgzs >> >> Pharo Smalltalk Screencasts: http://www.pharocasts.com/ >> Blog: http://magaloma.blogspot.com/ > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > > > -- www.tudorgirba.com "From an abstract enough point of view, any two things are similar."

March 7, 2011