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

Re: [Pharo-project] table widget

by Tudor Girba

Thanks, Carlos. I will give it a try. Cheers, Doru On 2 Aug 2009, at 18:55, Carlos Crosetti wrote: > Doru, I don`t think so. Please post to this mailing list if you find > such > table/grid morph. > > I am using the SGrid package found at map.squeak.org, I wokks in > Pharo as > well as Squeak 3.10. > You will be able to display an array of arrays of objects prividing > the > column names and a list of selectors to be sent to each cell. > > The simple example code is as follows: > > | table | > table := (GridMorph > from: #(joe jack ben sam mary sally jen) > performing: #(asString reverse allButFirst asHex hash)) title: > 'Simple Tab > table openInWorld. > ^ table > > Find attached the screenshot resulting from this code. > > I atempted to add per-column alinmgent to Sgrid but stumbled with my > lack of > morphic frameworl development knowledge. If you are interested in > building > on top of SGrid, I will be interested in collaborating (providing > specifications, teet cases). > > Carlos > > > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de Tudor > Girba > Enviado el: Sabado, 01 de Agosto de 2009 08:57 p.m. > Para: Pharo Development > Asunto: [Pharo-project] table widget > > > Hi, > > Is there a table widget in Morphic/Polymorph? > > I would features like: > - add columns > - sort the rows based on a column > - select a row > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Internal Virus Database is out-of-date. > Checked by AVG. > Version: 7.5.560 / Virus Database: 269.21.6/1323 - Release Date: > 10/03/2008 > 11:07 a.m. > > <sgrid.doc.doc>_______________________________________________ > 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 "To lead is not to demand things, it is to make them happen."

Aug. 3, 2009

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Damien Cassou

Hi Henry, On Mon, Aug 3, 2009 at 1:05 PM, Henrik Johansen<henrik.s.johansen(a)veloxit.no> wrote: > - System browsers do not have proper drop-shadows while dragged, thus > lag alot. > Resizing the browser by a moderate amount causes the correct shadow to > be used on a case by case basis, if you resize the entire Pharo window > by some amount, all new browsers will have the "proper" shadow. > > - Close/minimize buttons on windows in the background do not show > unless you hover over them. > This can be fixed by changing to another window theme, then back to > Watery2. please report these two bugs on the issue tracker in two different reports. Thank you -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Aug. 3, 2009

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Henrik Johansen

On Aug 3, 2009, at 1:15 04PM, Serge Stinckwich wrote: > On Mon, Aug 3, 2009 at 6:05 PM, Henrik > Johansen<henrik.s.johansen(a)veloxit.no> wrote: >> 2 things bugging me on Mac with the beta "dev" image: >> (Not sure if you could call them bugs, since they seem to be >> artifacts >> caused in some way by initialization needed but not done by the build >> script) >> >> - System browsers do not have proper drop-shadows while dragged, thus >> lag alot. >> Resizing the browser by a moderate amount causes the correct shadow >> to >> be used on a case by case basis, if you resize the entire Pharo >> window >> by some amount, all new browsers will have the "proper" shadow. >> >> - Close/minimize buttons on windows in the background do not show >> unless you hover over them. >> This can be fixed by changing to another window theme, then back to >> Watery2. > > Yes +1 for this one. > Maybe buttons can be drawn in gray when the focus is not on the > window, as done in mac os X UI. > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Smalltalkers do: [:it | All with: Class, (And love: it)] > http://doesnotunderstand.org/ > ThatÂ´s what they do, once you change theme and back again :) Cheers, Henry

Aug. 3, 2009

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Serge Stinckwich

On Mon, Aug 3, 2009 at 6:05 PM, Henrik Johansen<henrik.s.johansen(a)veloxit.no> wrote: > 2 things bugging me on Mac with the beta "dev" image: > (Not sure if you could call them bugs, since they seem to be artifacts > caused in some way by initialization needed but not done by the build > script) > > - System browsers do not have proper drop-shadows while dragged, thus > lag alot. > Resizing the browser by a moderate amount causes the correct shadow to > be used on a case by case basis, if you resize the entire Pharo window > by some amount, all new browsers will have the "proper" shadow. > > - Close/minimize buttons on windows in the background do not show > unless you hover over them. > This can be fixed by changing to another window theme, then back to > Watery2. Yes +1 for this one. Maybe buttons can be drawn in gray when the focus is not on the window, as done in mac os X UI. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Aug. 3, 2009

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Henrik Johansen

2 things bugging me on Mac with the beta "dev" image: (Not sure if you could call them bugs, since they seem to be artifacts caused in some way by initialization needed but not done by the build script) - System browsers do not have proper drop-shadows while dragged, thus lag alot. Resizing the browser by a moderate amount causes the correct shadow to be used on a case by case basis, if you resize the entire Pharo window by some amount, all new browsers will have the "proper" shadow. - Close/minimize buttons on windows in the background do not show unless you hover over them. This can be fixed by changing to another window theme, then back to Watery2. Cheers and congrats! Henry On Jul 31, 2009, at 10:42 05AM, Adrian Lienhard wrote: > Hi all, > > We are excited to announce the first Pharo 1.0 beta release. > > A new Pharo image (and also Pharo-web image) can be downloaded from > the website: > > http://pharo.cmsbox.ch/pharo-download > > The corresponding version number of Pharo-core is #10401. > > I'd like to thank all the people that have contributed to Pharo so > far! > > Have fun, > Adrian > > BTW, I also wrote about Pharo and the beta release on http://www.adrian-lienhard.ch/blog > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 3, 2009

[Pharo-project] Inria Mailinglist archive is not up to date

by Torsten Bergmann

Looks like the mailing list archive is not updated: http://lists.gforge.inria.fr/pipermail/pharo-project/2009-August/date.html -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

Aug. 3, 2009

Re: [Pharo-project] [squeak-dev] Re: Debbuging problems, FFI

by Mariano Martinez Peck

On Sun, Aug 2, 2009 at 11:57 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2009/8/2 Andreas Raab <andreas.raab(a)gmx.de>: > > Mariano Martinez Peck wrote: > >> > >> Javier has done an excellent job and here is his last post. Can someone > >> read what he found and see if we can fix this annoying bug? > > > > The problem is that you can't call #valueWithReceiver:args: since this > would > > both execute the entire method and do it in the wrong context where > instead > > you need to execute *just* the primitive (since you'll simulate the rest > if > > it fails). > > > > Fortunately, external functions have two ways to invoke them; one > implicitly > > as primitive in a method (i.e., prim 120) and another one explicitly (via > > invokeWithArgs:). A variant on the latter that returns > > ContextPart>>primFailToken does the trick nicely. > > > > I've updated both http://source.squeak.org/FFI and > > http://source.squeak.org/trunk with the ncessary bits. > > Andreas, does your change fixes the issue? Because its not clear from > your message - is it solves the problem altogether, or it is just a > first step towards proper fix? > Thanks Igor. I had the same questions as you. However, I downloaded that new version, and tried but I got same results (the behaviour of the first email). I mean, when I did step over in the api call I landed in and in MethodContext(ContextPart)>>runUntilErrorOrReturnFrom: > > > Cheers, > > - Andreas > > > >> > >> Thanks, > >> > >> Mariano > >> > >> > >> ---------- Forwarded message ---------- > >> From: *Javier PimÃ¡s* <elpochodelagente(a)gmail.com > >> <mailto:elpochodelagente@gmail.com>> > >> Date: 2009/8/2 > >> Subject: Re: [Pharo-project] Debbuging problems, FFI > >> To: Pharo-project(a)lists.gforge.inria.fr > >> <mailto:Pharo-project@lists.gforge.inria.fr> > >> > >> > >> I Think I found where the problem lies, it's just sitting there waiting > to > >> be resolved. > >> > >> To see what was happening I debugged the debuger, which was really > weird. > >> I found the answer when I broke into the step over button by adding a > self > >> break in OTCmdOverDebugger>>execute. After catching it I removed the > break > >> and stepped into everything to see how step over worked. The intresting > part > >> is in MethodContext(ContextPart)>>step, which sends > >> interpretNextInstructionFor: self. The idea is this, instead of > advancing > >> the vm program counter within the vm code, the debugger simulates the > >> execution cycle, step by step. It not so hard as it seems but also not > very > >> simple. The problem comes when the debugger tryies to simulate primitive > >> calls. When the simulator detects a primitive, it issues a > >> MethodContext(ContextPart)>>doPrimitive:method:receiver:args:, here you > can > >> see the detection: > >> > >> tryPrimitiveFor: method receiver: receiver args: arguments > >> "..." > >> | primIndex | > >> (primIndex := method primitive) = 0 ifTrue: [^ PrimitiveFailToken]. > >> ^ self doPrimitive: primIndex method: method receiver: receiver args: > >> arguments > >> > >> well, the problem is that doPrimitive doesn't seem to implement all > >> primitives (I recomend you to look it's code), but just a few ones. > Also, as > >> far as I can see, it calls primitive 19, which i found is (by looking vm > C > >> code) primitiveFail, and that primitive just sets a flag that says that > >> something failed. > >> > >> Then, if my calculations are correct, the problem is that the FFI Call > >> primitive needs to be handled by hand. I tryied adding this to > >> ContextPart>>doPrimitive:method:receiver:args: > >> > >> primitiveIndex = 120 ifTrue: "Calling an FFI method, just evaluate it > and > >> return" > >> [ meth valueWithReceiver: receiver arguments: arguments . ^self]. > >> > >> just before > >> > >> arguments size > 6 ifTrue: [^PrimitiveFailToken]. > >> > >> which I think almost worked. I think the primitive was executed, but > this > >> doesn't handle the execution context that is being simulated, and the > stack > >> gets corrupted. Somebody with more experience in ContextPart, > MethodContext, > >> etc. may give us a hand here, I think the fix is almost there. > >> > >> Bye, > >> Javier. > >> > >> 2009/7/31 Mariano Martinez Peck <marianopeck(a)gmail.com > >> <mailto:marianopeck@gmail.com>> > >> > >> > >> > >> 2009/7/31 Javier PimÃ¡s <elpochodelagente(a)gmail.com > >> <mailto:elpochodelagente@gmail.com>> > >> > >> Does anybody know if the problem occurs just in Windows or in > >> any OS? this can give a clue of the problem... > >> > >> > >> I don't remember debugging in Windows, but in Linux I have this > >> problem for sure. > >> > >> > >> On Thu, Jul 30, 2009 at 11:28 PM, Javier PimÃ¡s > >> <elpochodelagente(a)gmail.com <mailto:elpochodelagente@gmail.com>> > >> wrote: > >> > >> Well, at least I feel better that I'm not crazy, (or not the > >> only one...). Maybe if someone could give us a clue about > >> it, we could spot where the problem is. Do you think it is a > >> vm problem or something related to the smalltalk code? > >> > >> 2009/7/30 Mariano Martinez Peck <marianopeck(a)gmail.com > >> <mailto:marianopeck@gmail.com>> > >> > >> Yes. This is really annoying for me. I am writing a C > >> library plugin since a year and a half and this is very > >> frustrated :( > >> You cannot debug when using FFI. I mean, you cannot get > >> advantages of one of the best Smalltalk features! What I > >> do is to write a self break before and after the call > >> and use "proceed" but I don't like it at all. > >> > >> Once I tried to see what the problem was, but I was to > >> difficult to me to understand it and fix it. We need a > >> guru here I think hahaha. > >> > >> Best, > >> > >> Mariano > >> > >> 2009/7/30 Javier PimÃ¡s <elpochodelagente(a)gmail.com > >> <mailto:elpochodelagente@gmail.com>> > >> > >> Hi, I'm having problems with the debugger. Every > >> time I try to debug code that uses FFI, if I step > >> over a message that internally does an FFI call, I > >> get an externalCallFailed error and then I land in > >> > MethodContext(ContextPart)>>runUntilErrorOrReturnFrom: > >> If I run the code without debugging, then I have no > >> problems at all. > >> > >> I'm using SqueakPharo v3.11.2 with > >> pharo0.1-10373web09.07.2. > >> > >> To reproduce it you can try this: > >> > >> ScriptLoader loadFFI. > >> then load latest GLMorphic from squeaksource, and > >> uncomment the "self break." in > >> GLCanvas>>displayString:from:to:at:strikeFont:kern: > >> > >> doit > >> World fullDrawOn: GLDisplayScreen testCanvas > >> hit debug and step over until you reach > >> ogl glTexImage2D: GLTexture2d with:... > >> > >> also you'll see wrong values for local vars, like > >> aPoint which will look as #(nil nil nil nil nil) > >> when it'll actually have a point. > >> > >> Is there any other way to set up a break point > >> instead of adding self break to the code?? > >> > >> Thanks, > >> Javier. > >> > >> -- Javier PimÃ¡s > >> Ciudad de Buenos Aires > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> <mailto:Pharo-project@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 > >> <mailto:Pharo-project@lists.gforge.inria.fr> > >> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> > >> > >> -- Javier PimÃ¡s > >> Ciudad de Buenos Aires > >> > >> > >> > >> > >> -- Javier PimÃ¡s > >> Ciudad de Buenos Aires > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> <mailto:Pharo-project@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 > >> <mailto:Pharo-project@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 > >> <mailto:Pharo-project@lists.gforge.inria.fr> > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> ------------------------------------------------------------------------ > >> > >> > > > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Aug. 3, 2009

[Pharo-project] Debbuging problems, FFI

by Torsten Bergmann

see answer from Andreas: http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-August/137923.h… -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

Aug. 2, 2009

[Pharo-project] 2 new plugin (for VMPluginOverview)

by Torsten Bergmann

Maybe someone is able to include the following plugins in http://code.google.com/p/pharo/wiki/VMPluginOverview. Thanks Torsten OpenVGPlugin.dll ================ [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-August/137911.h… Cryptography.dll ================ http://leves.web.elte.hu/cryptography/ -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

Aug. 2, 2009

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Sebastian Sastre

1000 timesRepeat:['yay!']. 1000 timesRepeat:['thanks!']. 1000 timesRepeat:['Pharo rulez']. sebastian > -----Mensaje original----- > De: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] En > nombre de Adrian Lienhard > Enviado el: Friday, July 31, 2009 05:42 > Para: Pharo Development > Asunto: [Pharo-project] [ANN] Pharo 1.0 Beta > > Hi all, > > We are excited to announce the first Pharo 1.0 beta release. > > A new Pharo image (and also Pharo-web image) can be downloaded from > the website: > > http://pharo.cmsbox.ch/pharo-download > > The corresponding version number of Pharo-core is #10401. > > I'd like to thank all the people that have contributed to > Pharo so far! > > Have fun, > Adrian > > BTW, I also wrote about Pharo and the beta release on > http://www.adrian-lienhard.ch/blog > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 2, 2009