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

Re: [Pharo-project] Pharo name format

by StÃ©phane Ducasse

would be good > > Ok, I think this makes sense. I will use the following one: > The tag would allow to distinguish BETA vs. Release... > > PharoCore-1.0-10404-BETA.zip > > Should we create a wiki page for this decision ? >

Aug. 4, 2009

Re: [Pharo-project] Pharo name format

by Mariano Martinez Peck

On Tue, Aug 4, 2009 at 3:05 PM, Marcus Denker <denker(a)acm.org> wrote: > > On 31.07.2009, at 18:36, Miguel Enrique CobÃ¡ Martinez wrote: > > > Now that the release date for pharo is close, I propose to use the > > following sintax for the pharo core products > > > > PharoCore-x.y-#####-TagName.zip > > > > where > > x.y > > is the version of pharo (0.1, 1.0, 1.1, 2.0, 2.1, etc) > > ##### > > is the number of image release in that version (10449, 10450, 10451, > > etc) > > TagName > > is a tag for better explain some specific feature of the image > > (closure, RELEASE, STABLE, beta, etc) > > > > e.g. > > > > For a normal daily release, say 10450, in the 0.1 branch: > > > > PharoCore-0.1-10450.zip > > > > Ok, I think this makes sense. I will use the following one: > The tag would allow to distinguish BETA vs. Release... > > PharoCore-1.0-10404-BETA.zip > Should we create a wiki page for this decision ? > > > > For the image that has all tests in green: > > > > PharoCore-0.1-10456-AllTestGreen.zip > > > > For the image that it is the first stable 1.0: > > > > PharoCore-1.0-10478-RELEASE_1_0.zip > > > > For the next image with the NewCompiler code integrated, after the 1.0 > > release: > > > > PharoCore-1.0-10490-NewCompiler.zip > > > > For a subsecuent 1.1 release, that includes NewCompiler: > > > > PharoCore-1.1-10511-RELEASE_1_1.zip > > > > When, for example, 1.1 is the current branch, and 1.0 has fixes > > support > > and a new emergency release for the old 1.0 branch: > > > > PharoCore-1.0-10512-UPDATE_1.zip > > > > Release for pharo 2.0: > > > > PharoCore-2.0-10890-RELEASE_2_0.zip > > > > Other fix in the 1.1 branch (brach 1.0 is out of support): > > > > PharoCore-1.1-10915-UPDATE_1.zip > > > > Notes: We can also reset the number in each mayor release (0.1, 1.0, > > 1.1, etc) so that the updates to the old supportes branches can be a > > continuous. For example, the previous names would be (in the same > > order > > of release as the examples above): > > > > PharoCore-0.1-10450.zip > > > > PharoCore-0.1-10456-AllTestGreen.zip > > > > PharoCore-1.0-10001-RELEASE_1_0.zip > > > > PharoCore-1.0-10002-NewCompiler.zip > > > > PharoCore-1.1-10001-RELEASE_1_1.zip > > > > PharoCore-1.0-10003-UPDATE_1.zip > > > > PharoCore-2.0-10001-RELEASE_2_0.zip > > > > PharoCore-1.1-10002-UPDATE_1.zip > > > > etc > > > > Also, the PharoCore-1.0-10001-RELEASE_1_0.zip would be a copy of the > > last image of 0.1 branch (in this example > > PharoCore-0.1-10456-AllTestGreen.zip) > > > > But this is mostly estetic and can potentially confuse new users. > > > > What do you think? > > > > > > _______________________________________________ > > 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 >

Aug. 4, 2009

Re: [Pharo-project] Pharo name format

by Marcus Denker

On 31.07.2009, at 18:36, Miguel Enrique CobÃ¡ Martinez wrote: > Now that the release date for pharo is close, I propose to use the > following sintax for the pharo core products > > PharoCore-x.y-#####-TagName.zip > > where > x.y > is the version of pharo (0.1, 1.0, 1.1, 2.0, 2.1, etc) > ##### > is the number of image release in that version (10449, 10450, 10451, > etc) > TagName > is a tag for better explain some specific feature of the image > (closure, RELEASE, STABLE, beta, etc) > > e.g. > > For a normal daily release, say 10450, in the 0.1 branch: > > PharoCore-0.1-10450.zip > Ok, I think this makes sense. I will use the following one: The tag would allow to distinguish BETA vs. Release... PharoCore-1.0-10404-BETA.zip > For the image that has all tests in green: > > PharoCore-0.1-10456-AllTestGreen.zip > > For the image that it is the first stable 1.0: > > PharoCore-1.0-10478-RELEASE_1_0.zip > > For the next image with the NewCompiler code integrated, after the 1.0 > release: > > PharoCore-1.0-10490-NewCompiler.zip > > For a subsecuent 1.1 release, that includes NewCompiler: > > PharoCore-1.1-10511-RELEASE_1_1.zip > > When, for example, 1.1 is the current branch, and 1.0 has fixes > support > and a new emergency release for the old 1.0 branch: > > PharoCore-1.0-10512-UPDATE_1.zip > > Release for pharo 2.0: > > PharoCore-2.0-10890-RELEASE_2_0.zip > > Other fix in the 1.1 branch (brach 1.0 is out of support): > > PharoCore-1.1-10915-UPDATE_1.zip > > Notes: We can also reset the number in each mayor release (0.1, 1.0, > 1.1, etc) so that the updates to the old supportes branches can be a > continuous. For example, the previous names would be (in the same > order > of release as the examples above): > > PharoCore-0.1-10450.zip > > PharoCore-0.1-10456-AllTestGreen.zip > > PharoCore-1.0-10001-RELEASE_1_0.zip > > PharoCore-1.0-10002-NewCompiler.zip > > PharoCore-1.1-10001-RELEASE_1_1.zip > > PharoCore-1.0-10003-UPDATE_1.zip > > PharoCore-2.0-10001-RELEASE_2_0.zip > > PharoCore-1.1-10002-UPDATE_1.zip > > etc > > Also, the PharoCore-1.0-10001-RELEASE_1_0.zip would be a copy of the > last image of 0.1 branch (in this example > PharoCore-0.1-10456-AllTestGreen.zip) > > But this is mostly estetic and can potentially confuse new users. > > What do you think? > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2009

Re: [Pharo-project] keyboard shortcut open a warning

by Mariano Martinez Peck

On Tue, Aug 4, 2009 at 2:50 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Just a thought: if all available commands are accessible via a menu > (which they probably should be), and the menu indicates the shortcut > key, then the GUI would be self-explanatory and we would not need a > list of shortcuts. > That's true, however, not all shortcut are accessible by a menu. As an example to tab (move right a tab space) a piece of code, you have to do ctrl + shift + r or ctrl + shift + l to left. Or to write a ifTrue: (forget about the ugly of ifTrue haha) you can do ctrl + shift + t .... etc.. and all of those things are useful to do with shortcuts but there aren't in any menu. cheers, Mariano > > Adrian > > On Aug 4, 2009, at 17:41 , Marcus Denker wrote: > > > > > On 01.08.2009, at 18:19, Mariano Martinez Peck wrote: > > > >> > >> > >> On Sat, Aug 1, 2009 at 10:28 AM, Marcus Denker <denker(a)acm.org> > >> wrote: > >> On Friday, July 31, 2009, StÃ©phane Ducasse > >> <stephane.ducasse(a)inria.fr> wrote: > >>> may be we should simply remove that item. > >>> menu > >>> system > >>> keyboard shortcuts > >> > >> yes > >> > >> why? is there other way newbie and not so newbie people can see the > >> list of shortcuts? Using the mouse is ugly for me and I try to use > >> shortcut as much as possible. > >> > > > > Can you add a bugtracker entry for having some documentation/help > > menu? The problem with the shortcuts was that in itself, it > > was a bit lonly... but mayne a real help menu would make sense. > > > > Marcus > > _______________________________________________ > > 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 >

Aug. 4, 2009

Re: [Pharo-project] keyboard shortcut open a warning

by Adrian Lienhard

Just a thought: if all available commands are accessible via a menu (which they probably should be), and the menu indicates the shortcut key, then the GUI would be self-explanatory and we would not need a list of shortcuts. Adrian On Aug 4, 2009, at 17:41 , Marcus Denker wrote: > > On 01.08.2009, at 18:19, Mariano Martinez Peck wrote: > >> >> >> On Sat, Aug 1, 2009 at 10:28 AM, Marcus Denker <denker(a)acm.org> >> wrote: >> On Friday, July 31, 2009, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> may be we should simply remove that item. >>> menu >>> system >>> keyboard shortcuts >> >> yes >> >> why? is there other way newbie and not so newbie people can see the >> list of shortcuts? Using the mouse is ugly for me and I try to use >> shortcut as much as possible. >> > > Can you add a bugtracker entry for having some documentation/help > menu? The problem with the shortcuts was that in itself, it > was a bit lonly... but mayne a real help menu would make sense. > > Marcus > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2009

Re: [Pharo-project] keyboard shortcut open a warning

by Marcus Denker

On 01.08.2009, at 18:19, Mariano Martinez Peck wrote: > > > On Sat, Aug 1, 2009 at 10:28 AM, Marcus Denker <denker(a)acm.org> wrote: > On Friday, July 31, 2009, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > may be we should simply remove that item. > > menu > > system > > keyboard shortcuts > > yes > > why? is there other way newbie and not so newbie people can see the > list of shortcuts? Using the mouse is ugly for me and I try to use > shortcut as much as possible. > Can you add a bugtracker entry for having some documentation/help menu? The problem with the shortcuts was that in itself, it was a bit lonly... but mayne a real help menu would make sense. Marcus

Aug. 4, 2009

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

by StÃ©phane Ducasse

ok with me. Stef On Aug 2, 2009, at 3:37 PM, Adrian Lienhard wrote: > > On Aug 1, 2009, at 18:33 , Marcus Denker wrote: > >> >> On 01.08.2009, at 07:06, Serge Stinckwich wrote: >> >>> On Sat, Aug 1, 2009 at 2:41 AM, StÃ©phane >>> Ducasse<stephane.ducasse(a)inria.fr> wrote: >>>> So what is the process now? >>>> Do we focus on 1.0? >>>> Can we integrate other issues? >>>> Do we have a separate stream for 1.1 alpha? >>> >>> Maybe the 1.1 alpha should be available after the release of Pharo >>> 1.0 >>> so the efforts of the team is not disseminate on two versions. >> >> Yes, I think this is the way to go... we should force everyone to use >> the >> beta version for a while. > > Yes. We have 50 open issues for 1.0 and when more people start using > Pharo, they will find more bugs. So for now we should focus on > bringing that number down to 0. > > Adrian > >> >> Marcus >> >> >> >> >> -- >> Marcus Denker - http://marcusdenker.de >> PLEIAD Lab - Computer Science Department (DCC) - University of Chile >> >> >> _______________________________________________ >> 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

Aug. 4, 2009

Re: [Pharo-project] table widget

by StÃ©phane Ducasse

There is one. ask in the squeak mailing-list because I do not remember. and may be it is not working. On Aug 2, 2009, at 1:57 AM, Tudor Girba wrote: > 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

Aug. 4, 2009

Re: [Pharo-project] Custom user Interrupt handling

by StÃ©phane Ducasse

mike can you add a bugtrack entry for 1.1 on that topic? On Aug 2, 2009, at 12:42 AM, Michael Rueger wrote: > Dale Henrichs wrote: >> Michael, >> >> What's the approved method for unregistering the current user >> interrupt handler? >> >> InputEventFetcher default eventHandlers copy do: [:hndlr | >> (hndlr isKindOf: UserInterruptHandler) ifTrue: [ hndlr >> unregister]]. >> >> Looks like it would work, but seems a bit fragile. > > Hmm, well, that part obviously wasn't thought out well... > So your code above would do for now. A better way could be to have the > UserInterruptHandler class remember the current registered handler. > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 4, 2009

Re: [Pharo-project] Debbuging problems, FFI

by Mariano Martinez Peck

On Tue, Aug 4, 2009 at 12:30 PM, Marcus Denker <denker(a)acm.org> wrote: > > On 03.08.2009, at 23:57, Javier PimÃ¡s wrote: > > > I'm glad it worked, and very pleased with the fast responses. Now, > > how does this patch get merged to the pharo trunk? > > > > Can you add an entry to the bugtracker? > > http://code.google.com/p/pharo/issues/list > > I should have some good description or a changeset or a SLICE. Than I > add it to pharo today... > Marcus, I already opened the ticket: http://code.google.com/p/pharo/issues/detail?id=1029 You have to do 2 things to make it work: 1) download latest ffi (FFI-Kernel-ar.11). You can evaluate "ScriptLoader loadFFI" 2) filein the attached changeset (in ticket) to ContextPart>>doPrimitive: primitiveIndex method: meth receiver: receiver args: I am just looking for testers and feedback before commiting it to pharo inbox. Best, Mariano > > Marcus > > > > The other thing I'd like to find out is why when using self break, I > > get in the debugger inspector a context where variables have wrong > > values. I'll open another thread on this. > > > > 2009/8/3 Mariano Martinez Peck <marianopeck(a)gmail.com> > > Thanks Javier PimÃ¡s and Andreas Raab for the excellent debugging and > > work. Andreas propose a fix (based in Javier work) and he has > > commited to Squeak. I look at the changes and try them in pharo. It > > works perfect!!! > > > > So, here is the ticket I open for pharo: > http://code.google.com/p/pharo/issues/detail?id=1029 > > > > You have to do 2 things to make it work: > > > > 1) download latest ffi (FFI-Kernel-ar.11). You can evaluate > > "ScriptLoader > > loadFFI" > > > > 2) filein the attached changeset (in ticket) to > > ContextPart>>doPrimitive: > > primitiveIndex method: meth receiver: receiver args: > > > > Please test it and let me know the results so that this can be > > integrated. > > > > For me it worked perfect. > > > > Best, > > > > Mariano > > > > 2009/8/2 Javier PimÃ¡s <elpochodelagente(a)gmail.com> > > > > 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> > > > > > > > > 2009/7/31 Javier PimÃ¡s <elpochodelagente(a)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 > > > 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> > > > > 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> > > 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 > > 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 > > > > > > > > -- > > 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 > > 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 > > > > > > > > -- > > Javier PimÃ¡s > > Ciudad de Buenos Aires > > > > _______________________________________________ > > 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 > > > > > > > > -- > > Javier PimÃ¡s > > Ciudad de Buenos Aires > > _______________________________________________ > > 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 >

Aug. 4, 2009