Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
http://code.google.com/p/pharo/issues/detail?id=1738 There are still some issues. Some methods (for example TPureBehavior #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issue 1692: MNU when tried to navigate pop up menus with the keyboard
Mariano Martinez Peck a écrit : On Mon, Jan 4, 2010 at 7:58 AM, Alain Plantec alain.plan...@free.fr mailto:alain.plan...@free.fr wrote: Mariano Martinez Peck a écrit : Hi Alain: This bug seems related with the new preference architecture. indeed, I will check that very soon. Cool. Take it easy. No one is rushing :) SLICE-Issue1692-KeyboardFocusColor is in inbox. Thanks for reporting Alain Alain ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about and:and: and and:
The NewCompiler optimizes #and:and:and: to an optimized and nested #and:. The standard compiler does a normal message send with block activations for each condition and thus is dead slow. Lukas 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: hi nicolas I saw that you apply some automatic refactoring in squeak about and:and: - and: and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like to know for sure. Stef ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] What about killing PharoWeb images?
Please, don't say NO! immediately. Read the mail carefully, take a deep breath and think cold. After working a couple of weeks in the Metacello configurations and now with Damien's scripts to build Dev and Web images, I came to the question: Do we really need a PharoWeb image? I will give just my opinions of why having PharoWeb images is not a good idea anymore 1) First of all, I don't like the PharoWeb name. Because it is not Web in general, it is seaside. So, in my opinion, a better name would be PharoSeaside. Maybe even new comers may think that the only alternative is seaside. You know I have nothing against Seaside and that I even use it several times. I would like to see AidaWeb images based in Pharo too. 2) Why to still have PharoWeb images if now Seaside images (at least the one click) are based in seaside ? In addition, when I develop in Seaside, I use Seaside images, not PharoWeb, and I think most people do the same. 3) Seaside images (or Lukas images for seaside) are MUCH more stable than the PharoWeb images. Why? Several reasons: 3.a) THEY know the dependencies of the packages, the versions, how to set up, the order of load, etc, NOT us. THEY are the experts in seaside, not us. 3.b) THEY really test their images before make then public. 3.c) We are force to release one release per month which has no sense. How says that Seaside is released once a month? That's bad because it means we are usually taking unstable versions. THEY know when a release should be done and when a release is stable or not. 4) Now I created all the Metacello configurations for the PharoDev image and I took me a lot of time. Because I am not the developer of any of those projects. So, I need to understand the dependencies, the order, the versions, etc. But why ??? If Seaside people have already done that, don't duplicate efforts. 5) The instability of PharoWeb images give to our public a bad impression. We waste all of out efforts of Pharo in that image. 6) The idea of Pharo is to be the vehicle. And that's exactly the Pharo role in the Seaside images. We don't need to build PharoWeb images. Even more, do we build PharoGlass images ? N. Why not ? Because Dale already prepare them and as HE knows much more about Glass than us, his images are better for Glass. 7) Tracking and managing issues always take time. Even analyzing a bug, say we won't fix and close it. With PharoWeb images we are having those kind of issues. 8) Our resources are limited. Why not to use them in more important stuff ? For example, building a better and more robust Dev image? Here is my proposal: 1) Completely remove the idea of PharoWeb image. Remove the links from the website and do not create Web images any more. 2) In http://www.pharo-project.org/pharo-download add a description explaining that now Seaside images are based in Pharo, so you can directly download that image. We can even explain a bit about seaside, and even if you want you can put a href called PharoWeb which links to the seaside image. However, I would rather call it PharoSeaside. 3) Tomorrow we can have AidaWeb images based in pharo (please Janko!!) so we can just do the same and put the link to those images. 4) You may notice that Seaside images are a bit different than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more similar to our Dev images, just run that script. So...what do you think? I would really like to hear your opinion about this. Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about and:and: and and:
My point was: - these messages are Squeak specific - they are slow (didn't knew about NewCompiler...) - do they really add some value over nested and: ? Nicolas 2010/1/4 Lukas Renggli reng...@gmail.com: The NewCompiler optimizes #and:and:and: to an optimized and nested #and:. The standard compiler does a normal message send with block activations for each condition and thus is dead slow. Lukas 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: hi nicolas I saw that you apply some automatic refactoring in squeak about and:and: - and: and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like to know for sure. Stef ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
On Jan 4, 2010, at 9:24 AM, Mariano Martinez Peck wrote: Please, don't say NO! immediately. Read the mail carefully, take a deep breath and think cold. After working a couple of weeks in the Metacello configurations and now with Damien's scripts to build Dev and Web images, I came to the question: Do we really need a PharoWeb image? we dont :) I agree with you. I will give just my opinions of why having PharoWeb images is not a good idea anymore 1) First of all, I don't like the PharoWeb name. Because it is not Web in general, it is seaside. So, in my opinion, a better name would be PharoSeaside. Maybe even new comers may think that the only alternative is seaside. You know I have nothing against Seaside and that I even use it several times. I would like to see AidaWeb images based in Pharo too. 2) Why to still have PharoWeb images if now Seaside images (at least the one click) are based in seaside ? In addition, when I develop in Seaside, I use Seaside images, not PharoWeb, and I think most people do the same. 3) Seaside images (or Lukas images for seaside) are MUCH more stable than the PharoWeb images. Why? Several reasons: 3.a) THEY know the dependencies of the packages, the versions, how to set up, the order of load, etc, NOT us. THEY are the experts in seaside, not us. 3.b) THEY really test their images before make then public. 3.c) We are force to release one release per month which has no sense. How says that Seaside is released once a month? That's bad because it means we are usually taking unstable versions. THEY know when a release should be done and when a release is stable or not. 4) Now I created all the Metacello configurations for the PharoDev image and I took me a lot of time. Because I am not the developer of any of those projects. So, I need to understand the dependencies, the order, the versions, etc. But why ??? If Seaside people have already done that, don't duplicate efforts. 5) The instability of PharoWeb images give to our public a bad impression. We waste all of out efforts of Pharo in that image. 6) The idea of Pharo is to be the vehicle. And that's exactly the Pharo role in the Seaside images. We don't need to build PharoWeb images. Even more, do we build PharoGlass images ? N. Why not ? Because Dale already prepare them and as HE knows much more about Glass than us, his images are better for Glass. 7) Tracking and managing issues always take time. Even analyzing a bug, say we won't fix and close it. With PharoWeb images we are having those kind of issues. 8) Our resources are limited. Why not to use them in more important stuff ? For example, building a better and more robust Dev image? Here is my proposal: 1) Completely remove the idea of PharoWeb image. Remove the links from the website and do not create Web images any more. 2) In http://www.pharo-project.org/pharo-download add a description explaining that now Seaside images are based in Pharo, so you can directly download that image. We can even explain a bit about seaside, and even if you want you can put a href called PharoWeb which links to the seaside image. However, I would rather call it PharoSeaside. 3) Tomorrow we can have AidaWeb images based in pharo (please Janko!!) so we can just do the same and put the link to those images. 4) You may notice that Seaside images are a bit different than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more similar to our Dev images, just run that script. So...what do you think? I would really like to hear your opinion about this. Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about and:and: and and:
Thanks lukas so we could get rid of them :) Stef On Jan 4, 2010, at 9:12 AM, Lukas Renggli wrote: The NewCompiler optimizes #and:and:and: to an optimized and nested #and:. The standard compiler does a normal message send with block activations for each condition and thus is dead slow. Lukas 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: hi nicolas I saw that you apply some automatic refactoring in squeak about and:and: - and: and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like to know for sure. Stef ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about and:and: and and:
Nicolas I would love to get the latest version cleanup automatically If by accident a huge slice would be committed into the pharoInbox. what the others think? Stef On Jan 4, 2010, at 9:26 AM, Nicolas Cellier wrote: My point was: - these messages are Squeak specific - they are slow (didn't knew about NewCompiler...) - do they really add some value over nested and: ? Nicolas 2010/1/4 Lukas Renggli reng...@gmail.com: The NewCompiler optimizes #and:and:and: to an optimized and nested #and:. The standard compiler does a normal message send with block activations for each condition and thus is dead slow. Lukas 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: hi nicolas I saw that you apply some automatic refactoring in squeak about and:and: - and: and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like to know for sure. Stef ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
1) First of all, I don't like the PharoWeb name. Because it is not Web in general, it is seaside. So, in my opinion, a better name would be PharoSeaside. Maybe even new comers may think that the only alternative is seaside. You know I have nothing against Seaside and that I even use it several times. I would like to see AidaWeb images based in Pharo too. I think at some point the images also contained AIDA. 4) Now I created all the Metacello configurations for the PharoDev image and I took me a lot of time. Because I am not the developer of any of those projects. So, I need to understand the dependencies, the order, the versions, etc. But why ??? If Seaside people have already done that, don't duplicate efforts. There is a configuration for Seaside 3.0 (and probably also Seaside 2.8). This was probably the first configuration every written. Ask Dale. 4) You may notice that Seaside images are a bit different than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more similar to our Dev images, just run that script. They are different because they reflect my preferences. I basically build the Seaside images for me. If other people like and use these images, that's great of course. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about and:and: and and:
From Slime: RBParseTreeRewriter new replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 ] ]'; replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ] and: [ | `...@temp4 | `...@expr4 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 and: [ | `...@temp4 | `...@expr4 ] ] ]'; replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ] and: [ | `...@temp4 | `...@expr4 ] and: [ | `...@temp5 | `...@expr5 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 and: [ | `...@temp4 | `...@expr4 and: [ | `...@temp5 | `...@expr5 ] ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ] or: [ | `...@temp5 | `...@expr5 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 or: [ | `...@temp5 | `...@expr5 ] ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ] or: [ | `...@temp5 | `...@expr5 ] or: [ | `...@temp6 | `...@expr6 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 or: [ | `...@temp5 | `...@expr5 or: [ | `...@temp6 | `...@expr6 ] ] ] ] ]'; yourself 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: Nicolas I would love to get the latest version cleanup automatically If by accident a huge slice would be committed into the pharoInbox. what the others think? Stef On Jan 4, 2010, at 9:26 AM, Nicolas Cellier wrote: My point was: - these messages are Squeak specific - they are slow (didn't knew about NewCompiler...) - do they really add some value over nested and: ? Nicolas 2010/1/4 Lukas Renggli reng...@gmail.com: The NewCompiler optimizes #and:and:and: to an optimized and nested #and:. The standard compiler does a normal message send with block activations for each condition and thus is dead slow. Lukas 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: hi nicolas I saw that you apply some automatic refactoring in squeak about and:and: - and: and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like to know for sure. Stef ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Simple question about NewInspector
RoelTyper is also used in ProtoObjectniChildrenBlockForFixedFields (an extension for NewInspector). NewInspector can work without RoelTyper. The message The last version of RoelTyper must be loaded to have this information is shown when NewInspector tries to calculate types and that RoelTyper is not found. Fréd Frédéric Pluquet Université Libre de Bruxelles (ULB) Assistant http://www.ulb.ac.be/di/fpluquet On Sat, Dec 26, 2009 at 11:29 PM, Mariano Martinez Peck marianop...@gmail.com wrote: Hi Frederic. I am trying to see if it make sense to create a metacello configuration for NewInspector. The only external (not in PharoCore) dependency I saw using the DependencyBrowser is RoelTyper, which is used in the class NICompiledMethodNode configurationyou use the class TypeCollector which is from RoelTyper. So, the question is, is this dependency correct? I ask because I took a PharoCore image, load NewINspector WITHOUT RoelTyper and it seemed to work. Thank you very much. Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
On Mon, Jan 4, 2010 at 9:45 AM, Lukas Renggli reng...@gmail.com wrote: 1) First of all, I don't like the PharoWeb name. Because it is not Web in general, it is seaside. So, in my opinion, a better name would be PharoSeaside. Maybe even new comers may think that the only alternative is seaside. You know I have nothing against Seaside and that I even use it several times. I would like to see AidaWeb images based in Pharo too. I think at some point the images also contained AIDA. No it doesn't. Not at least in the lasts images I have and in the scripts I have. 4) Now I created all the Metacello configurations for the PharoDev image and I took me a lot of time. Because I am not the developer of any of those projects. So, I need to understand the dependencies, the order, the versions, etc. But why ??? If Seaside people have already done that, don't duplicate efforts. There is a configuration for Seaside 3.0 (and probably also Seaside 2.8). This was probably the first configuration every written. Ask Dale. yes, that's true. 4) You may notice that Seaside images are a bit different than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more similar to our Dev images, just run that script. They are different because they reflect my preferences. yes, of course. That's why I propose a little script that changes that to something more like our dev images. I basically build the Seaside images for me. Wait... The Seaside one click images and any other image that it is in the seaside website is not for you. I guess they are for the public. If other people like and use these images, that's great of course. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about and:and: and and:
If this preserves formatting, proceed, else, beware. Given there were few senders in trunk, my change was manual, not automatic (Steph didn't you mean systematic ?). Nicolas 2010/1/4 Lukas Renggli reng...@gmail.com: From Slime: RBParseTreeRewriter new replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 ] ]'; replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ] and: [ | `...@temp4 | `...@expr4 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 and: [ | `...@temp4 | `...@expr4 ] ] ]'; replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ] and: [ | `...@temp4 | `...@expr4 ] and: [ | `...@temp5 | `...@expr5 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 and: [ | `...@temp4 | `...@expr4 and: [ | `...@temp5 | `...@expr5 ] ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ] or: [ | `...@temp5 | `...@expr5 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 or: [ | `...@temp5 | `...@expr5 ] ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ] or: [ | `...@temp5 | `...@expr5 ] or: [ | `...@temp6 | `...@expr6 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 or: [ | `...@temp5 | `...@expr5 or: [ | `...@temp6 | `...@expr6 ] ] ] ] ]'; yourself 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: Nicolas I would love to get the latest version cleanup automatically If by accident a huge slice would be committed into the pharoInbox. what the others think? Stef On Jan 4, 2010, at 9:26 AM, Nicolas Cellier wrote: My point was: - these messages are Squeak specific - they are slow (didn't knew about NewCompiler...) - do they really add some value over nested and: ? Nicolas 2010/1/4 Lukas Renggli reng...@gmail.com: The NewCompiler optimizes #and:and:and: to an optimized and nested #and:. The standard compiler does a normal message send with block activations for each condition and thus is dead slow. Lukas 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: hi nicolas I saw that you apply some automatic refactoring in squeak about and:and: - and: and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like to know for sure. Stef ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
hmm. i thought i fixed this one. 2010/1/4 Levente Uzonyi le...@elte.hu: On Wed, 30 Dec 2009, Stéphane Ducasse wrote: BIG THANKS igor!!! 11127 - - Issue 1690: New Method Trailer part 7 (cs 9) There are still some issues. Some methods (for example TPureBehavior #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) Levente ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
I basically build the Seaside images for me. Wait... The Seaside one click images and any other image that it is in the seaside website is not for you. I guess they are for the public. No, they are not designed for the public, I build the images only for me. The fact that I put them on seaside.st is because people asked us to do so and this is really easy. If people like the images and it helps them, then this is great. If you are really into building images, you should build them for YOU and not for anybody else. Otherwise, I think, they are never going to fly. Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Mac VM 5.2.b2 ships
I've push the latest cocoa based 32/64bit macintel/powerpc VM There was a back-leveled patch for the JPEG2 read/writer which causes the Seasides tests to crash the VM. This is fixed. Look for the folder experimental/64bits in the regular places found via http://smalltalkconsulting.com/squeak.html or ftp://ftp.smalltalkconsulting.com/experimental/64bit/32bitImage*64bitVM/ file name: Squeak 64-32 5.2b2.app.zip This *beta* VM runs in 32 or 64 bit mode on macIntel, and 32bit mode on powerpc to support Squeak 32bit images. -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about and:and: and and:
This very likely does not preserve the formatting. The rewrite completely restructures the AST. Lukas 2010/1/4 Nicolas Cellier nicolas.cellier.aka.n...@gmail.com: If this preserves formatting, proceed, else, beware. Given there were few senders in trunk, my change was manual, not automatic (Steph didn't you mean systematic ?). Nicolas 2010/1/4 Lukas Renggli reng...@gmail.com: From Slime: RBParseTreeRewriter new replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 ] ]'; replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ] and: [ | `...@temp4 | `...@expr4 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 and: [ | `...@temp4 | `...@expr4 ] ] ]'; replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ] and: [ | `...@temp4 | `...@expr4 ] and: [ | `...@temp5 | `...@expr5 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 and: [ | `...@temp4 | `...@expr4 and: [ | `...@temp5 | `...@expr5 ] ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ] or: [ | `...@temp5 | `...@expr5 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 or: [ | `...@temp5 | `...@expr5 ] ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ] or: [ | `...@temp5 | `...@expr5 ] or: [ | `...@temp6 | `...@expr6 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 or: [ | `...@temp5 | `...@expr5 or: [ | `...@temp6 | `...@expr6 ] ] ] ] ]'; yourself 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: Nicolas I would love to get the latest version cleanup automatically If by accident a huge slice would be committed into the pharoInbox. what the others think? Stef On Jan 4, 2010, at 9:26 AM, Nicolas Cellier wrote: My point was: - these messages are Squeak specific - they are slow (didn't knew about NewCompiler...) - do they really add some value over nested and: ? Nicolas 2010/1/4 Lukas Renggli reng...@gmail.com: The NewCompiler optimizes #and:and:and: to an optimized and nested #and:. The standard compiler does a normal message send with block activations for each condition and thus is dead slow. Lukas 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: hi nicolas I saw that you apply some automatic refactoring in squeak about and:and: - and: and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like to know for sure. Stef ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr
Re: [Pharo-project] [Seaside] Mac VM 5.2b1 ships
John: Another problem I found is that I cannot open more than one image at the same time with this VM. Is this expected? Cheers Mariano On Sun, Jan 3, 2010 at 9:28 PM, Stéphane Ducasse stephane.duca...@inria.frwrote: Hi I asked abotu alien because at Amsterdam eliot used bird names to refer to FFI implementation. So I was thinking that building on top of Alien was a move into the future. May be you should talk with eliot. Stef 64-bit FFI will work on Unix and Windows with these fixes. I have not tried Mac, but I expect that some work would be needed. The changes are not trivial, and will affect the plugin, the VM itself, and the Pharo/Squeak images. The next big fix on our VM-team to-do list is to get sound working on 64-bit platforms, and FFI will come after that. I do not know the status of alien now, but my understanding is that it is limited to intel processors and 32-bit platforms. My guess is that it would be good to fix the old FFI first because those changes would likely have an impact on alien also. But I do not know much about alien, so I am not the best person to say. Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
Mariano Martinez Peck wrote: Please, don't say NO! immediately. Read the mail carefully, take a deep breath and think cold. After working a couple of weeks in the Metacello configurations and now with Damien's scripts to build Dev and Web images, I came to the question: Do we really need a PharoWeb image? I will give just my opinions of why having PharoWeb images is not a good idea anymore 1) First of all, I don't like the PharoWeb name. Because it is not Web in general, it is seaside. So, in my opinion, a better name would be PharoSeaside. Maybe even new comers may think that the only alternative is seaside. You know I have nothing against Seaside and that I even use it several times. I would like to see AidaWeb images based in Pharo too. 2) Why to still have PharoWeb images if now Seaside images (at least the one click) are based in seaside ? In addition, when I develop in Seaside, I use Seaside images, not PharoWeb, and I think most people do the same. 3) Seaside images (or Lukas images for seaside) are MUCH more stable than the PharoWeb images. Why? Several reasons: 3.a) THEY know the dependencies of the packages, the versions, how to set up, the order of load, etc, NOT us. THEY are the experts in seaside, not us. 3.b) THEY really test their images before make then public. 3.c) We are force to release one release per month which has no sense. How says that Seaside is released once a month? That's bad because it means we are usually taking unstable versions. THEY know when a release should be done and when a release is stable or not. 4) Now I created all the Metacello configurations for the PharoDev image and I took me a lot of time. Because I am not the developer of any of those projects. So, I need to understand the dependencies, the order, the versions, etc. But why ??? If Seaside people have already done that, don't duplicate efforts. 5) The instability of PharoWeb images give to our public a bad impression. We waste all of out efforts of Pharo in that image. 6) The idea of Pharo is to be the vehicle. And that's exactly the Pharo role in the Seaside images. We don't need to build PharoWeb images. Even more, do we build PharoGlass images ? N. Why not ? Because Dale already prepare them and as HE knows much more about Glass than us, his images are better for Glass. 7) Tracking and managing issues always take time. Even analyzing a bug, say we won't fix and close it. With PharoWeb images we are having those kind of issues. 8) Our resources are limited. Why not to use them in more important stuff ? For example, building a better and more robust Dev image? Here is my proposal: 1) Completely remove the idea of PharoWeb image. Remove the links from the website and do not create Web images any more. 2) In http://www.pharo-project.org/pharo-download add a description explaining that now Seaside images are based in Pharo, so you can directly download that image. We can even explain a bit about seaside, and even if you want you can put a href called PharoWeb which links to the seaside image. However, I would rather call it PharoSeaside. 3) Tomorrow we can have AidaWeb images based in pharo (please Janko!!) so we can just do the same and put the link to those images. 4) You may notice that Seaside images are a bit different than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more similar to our Dev images, just run that script. So...what do you think? I would really like to hear your opinion about this. Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project +1 I would definitely support concentrating on the Seaside one click images. As Mariano says, they're pretty stable, so you can get on with developing in them. From a marketing point of view, the one click images are much easier for someone who is evaluating Pharo for the first time. Also, the existing web dev is not the advertisement for Pharo that we want. There is a (very) slight complication. Lukas's recommendation for people starting a new project with JavaScript is to use JQueryUI, hence this implies Seaside 3.0. The Seaside 3.0 image on the Seaside site is not an official release: http://n4.nabble.com/2-1Using-the-One-Click-Image-tt975474.html#a975784 http://n4.nabble.com/2-1Using-the-One-Click-Image-tt975474.html#a975784 So the ideal solution is that that version become an official 3.0 one-click, although this was not in the Seaside plan. And maybe at the same time the Seaside team could apply (or allow to be applied) the few changes that Mariano mentioned to make
Re: [Pharo-project] Code Critics pragmas for classes - do they need to be on instance *and* class side?
Lukas Renggli wrote: I was specifically thinking of class not referenced, which seems strange to have to put on both sides. But I suppose there could be other class checks for which there could be utility in treating class and instance separately; I haven't come across a case so far. Ok, you convinced me. I've fixed this (but not tested it) in Refactoring-Core-lr.93. Let me know if this is better. Name: Refactoring-Core-lr.93 Author: lr Time: 3 January 2010, 3:25:42 pm UUID: c8f01646-b4cc-420a-a05e-dd8a0a81a305 Ancestors: Refactoring-Core-TestRunner.92 - for lint issues in class environments filter the instance and class side Lukas ...Stan -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project That's a lot tidier, thanks....Stan -- View this message in context: http://n2.nabble.com/Code-Critics-pragmas-for-classes-do-they-need-to-be-on-instance-and-class-side-tp4244276p4249436.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
We certainly don't need the web images, but I would like to see them stay to help with testing. If we are building them with unstable versions of Seaside, that is a problem with the process (loading the wrong stuff) not the concept/service (providing a Seaside-ready version of Pharo for testing). We just finished designing a beta program, at least three of volunteers indicated a preference for the web image. Bill From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck Sent: Monday, January 04, 2010 3:25 AM To: Pharo Development Subject: [Pharo-project] What about killing PharoWeb images? Please, don't say NO! immediately. Read the mail carefully, take a deep breath and think cold. After working a couple of weeks in the Metacello configurations and now with Damien's scripts to build Dev and Web images, I came to the question: Do we really need a PharoWeb image? I will give just my opinions of why having PharoWeb images is not a good idea anymore 1) First of all, I don't like the PharoWeb name. Because it is not Web in general, it is seaside. So, in my opinion, a better name would be PharoSeaside. Maybe even new comers may think that the only alternative is seaside. You know I have nothing against Seaside and that I even use it several times. I would like to see AidaWeb images based in Pharo too. 2) Why to still have PharoWeb images if now Seaside images (at least the one click) are based in seaside ? In addition, when I develop in Seaside, I use Seaside images, not PharoWeb, and I think most people do the same. 3) Seaside images (or Lukas images for seaside) are MUCH more stable than the PharoWeb images. Why? Several reasons: 3.a) THEY know the dependencies of the packages, the versions, how to set up, the order of load, etc, NOT us. THEY are the experts in seaside, not us. 3.b) THEY really test their images before make then public. 3.c) We are force to release one release per month which has no sense. How says that Seaside is released once a month? That's bad because it means we are usually taking unstable versions. THEY know when a release should be done and when a release is stable or not. 4) Now I created all the Metacello configurations for the PharoDev image and I took me a lot of time. Because I am not the developer of any of those projects. So, I need to understand the dependencies, the order, the versions, etc. But why ??? If Seaside people have already done that, don't duplicate efforts. 5) The instability of PharoWeb images give to our public a bad impression. We waste all of out efforts of Pharo in that image. 6) The idea of Pharo is to be the vehicle. And that's exactly the Pharo role in the Seaside images. We don't need to build PharoWeb images. Even more, do we build PharoGlass images ? N. Why not ? Because Dale already prepare them and as HE knows much more about Glass than us, his images are better for Glass. 7) Tracking and managing issues always take time. Even analyzing a bug, say we won't fix and close it. With PharoWeb images we are having those kind of issues. 8) Our resources are limited. Why not to use them in more important stuff ? For example, building a better and more robust Dev image? Here is my proposal: 1) Completely remove the idea of PharoWeb image. Remove the links from the website and do not create Web images any more. 2) In http://www.pharo-project.org/pharo-download add a description explaining that now Seaside images are based in Pharo, so you can directly download that image. We can even explain a bit about seaside, and even if you want you can put a href called PharoWeb which links to the seaside image. However, I would rather call it PharoSeaside. 3) Tomorrow we can have AidaWeb images based in pharo (please Janko!!) so we can just do the same and put the link to those images. 4) You may notice that Seaside images are a bit different than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more similar to our Dev images, just run that script. So...what do you think? I would really like to hear your opinion about this. Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 64 bit images (was Re: [squeak-dev] The Trunk: Collections-dtl.268.mcz)
Jannik did you check the changeset in the mantis bug report? Stef On Jan 4, 2010, at 10:53 AM, Laval Jannik wrote: Hi, I made a new version of the system-tracer (in attachment). It works fine with the latest pharo version. For wordSize, we decide to create a instance variable in SmalltalkImage, which is initialized at startup. The method initialPC is: --- initialPC Answer the program counter for the receiver's first bytecode. ^ (self numLiterals + 1) * SmalltalkImage current wordSize + 1 --- The fix will be integrated in Pharo soon. It is also in attachment. addWordSizeInSystemDictionary.1.csSystem-Tracing-forPharo.cs Cheers On Jan 3, 2010, at 06:46 , John M McIntosh wrote: Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image On 2010-01-02, at 6:46 PM, David T. Lewis wrote: John, one additional note. The SystemTracer changesets currently in circulation have an obsolete implementation of SystemDictionarywordSize.The original 64-bit Squeak used vmParameterAt: 27 for the VM to answer its word size, but this was later changed to vmParameter at: 40. This is the reason that the original dist3 64-bit image does not work on current VMs. You will want to revert #wordSize back to a current version so that it uses vmParameter at: 40. This issue will go away when we implement the cached #wordSize fixes discussed separately (http://bugs.squeak.org/view.php?id=7430), but I wanted to mention it because I spotted the obsolete method in the System-Tracing2forPharo.cs change set. -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === --- Jannik Laval --- ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about and:and: and and:
You did that manually :) Ok so may be since there are only few senders I can do it too :) Stef If this preserves formatting, proceed, else, beware. Given there were few senders in trunk, my change was manual, not automatic (Steph didn't you mean systematic ?). Nicolas 2010/1/4 Lukas Renggli reng...@gmail.com: From Slime: RBParseTreeRewriter new replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 ] ]'; replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ] and: [ | `...@temp4 | `...@expr4 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 and: [ | `...@temp4 | `...@expr4 ] ] ]'; replace: '`...@expr1 and: [ | `...@temp2 | `...@expr2 ] and: [ | `...@temp3 | `...@expr3 ] and: [ | `...@temp4 | `...@expr4 ] and: [ | `...@temp5 | `...@expr5 ]' with: '`...@expr1 and: [ | `...@temp2 | `...@expr2 and: [ | `...@temp3 | `...@expr3 and: [ | `...@temp4 | `...@expr4 and: [ | `...@temp5 | `...@expr5 ] ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ] or: [ | `...@temp5 | `...@expr5 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 or: [ | `...@temp5 | `...@expr5 ] ] ] ]'; replace: '`...@expr1 or: [ | `...@temp2 | `...@expr2 ] or: [ | `...@temp3 | `...@expr3 ] or: [ | `...@temp4 | `...@expr4 ] or: [ | `...@temp5 | `...@expr5 ] or: [ | `...@temp6 | `...@expr6 ]' with: '`...@expr1 or: [ | `...@temp2 | `...@expr2 or: [ | `...@temp3 | `...@expr3 or: [ | `...@temp4 | `...@expr4 or: [ | `...@temp5 | `...@expr5 or: [ | `...@temp6 | `...@expr6 ] ] ] ] ]'; yourself 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: Nicolas I would love to get the latest version cleanup automatically If by accident a huge slice would be committed into the pharoInbox. what the others think? Stef On Jan 4, 2010, at 9:26 AM, Nicolas Cellier wrote: My point was: - these messages are Squeak specific - they are slow (didn't knew about NewCompiler...) - do they really add some value over nested and: ? Nicolas 2010/1/4 Lukas Renggli reng...@gmail.com: The NewCompiler optimizes #and:and:and: to an optimized and nested #and:. The standard compiler does a normal message send with block activations for each condition and thus is dead slow. Lukas 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: hi nicolas I saw that you apply some automatic refactoring in squeak about and:and: - and: and I wanted to know. Is and: more optimized than and:and: (I imagine that) but I would like to know for sure. Stef ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] About moving tmp closer their use
Hi guys in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete system so that |temp| declaration would be at the scope where they are used. This is not clear that this is an optimisation but I like the fact that temp are defined at the right place. Now it may lead to code that is a bit less readable in the sense that your temps are not systematically listed at the beginning of the method but occasionally in the closures that use them. From my hackish lisping state of mind I like it now what do you prefer? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] 64 bit images (was Re: [squeak-dev] The Trunk: Collections-dtl.268.mcz)
Yes, but the changeset build the fix in SystemDictionary, In a previous discussion, we decide to create an instance variable in SmalltalkImage and to put methods in SmalltalkImage too. Cheers, Jannik On Jan 4, 2010, at 13:35 , Stéphane Ducasse wrote: Jannik did you check the changeset in the mantis bug report? Stef On Jan 4, 2010, at 10:53 AM, Laval Jannik wrote: Hi, I made a new version of the system-tracer (in attachment). It works fine with the latest pharo version. For wordSize, we decide to create a instance variable in SmalltalkImage, which is initialized at startup. The method initialPC is: --- initialPC Answer the program counter for the receiver's first bytecode. ^ (self numLiterals + 1) * SmalltalkImage current wordSize + 1 --- The fix will be integrated in Pharo soon. It is also in attachment. addWordSizeInSystemDictionary.1.csSystem-Tracing-forPharo.cs Cheers On Jan 3, 2010, at 06:46 , John M McIntosh wrote: Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image On 2010-01-02, at 6:46 PM, David T. Lewis wrote: John, one additional note. The SystemTracer changesets currently in circulation have an obsolete implementation of SystemDictionarywordSize.The original 64-bit Squeak used vmParameterAt: 27 for the VM to answer its word size, but this was later changed to vmParameter at: 40. This is the reason that the original dist3 64-bit image does not work on current VMs. You will want to revert #wordSize back to a current version so that it uses vmParameter at: 40. This issue will go away when we implement the cached #wordSize fixes discussed separately (http://bugs.squeak.org/view.php?id=7430), but I wanted to mention it because I spotted the obsolete method in the System-Tracing2forPharo.cs change set. -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === --- Jannik Laval --- ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
Hi Mariano, I also agree with you. Cheers, Doru On 4 Jan 2010, at 09:24, Mariano Martinez Peck wrote: Please, don't say NO! immediately. Read the mail carefully, take a deep breath and think cold. After working a couple of weeks in the Metacello configurations and now with Damien's scripts to build Dev and Web images, I came to the question: Do we really need a PharoWeb image? I will give just my opinions of why having PharoWeb images is not a good idea anymore 1) First of all, I don't like the PharoWeb name. Because it is not Web in general, it is seaside. So, in my opinion, a better name would be PharoSeaside. Maybe even new comers may think that the only alternative is seaside. You know I have nothing against Seaside and that I even use it several times. I would like to see AidaWeb images based in Pharo too. 2) Why to still have PharoWeb images if now Seaside images (at least the one click) are based in seaside ? In addition, when I develop in Seaside, I use Seaside images, not PharoWeb, and I think most people do the same. 3) Seaside images (or Lukas images for seaside) are MUCH more stable than the PharoWeb images. Why? Several reasons: 3.a) THEY know the dependencies of the packages, the versions, how to set up, the order of load, etc, NOT us. THEY are the experts in seaside, not us. 3.b) THEY really test their images before make then public. 3.c) We are force to release one release per month which has no sense. How says that Seaside is released once a month? That's bad because it means we are usually taking unstable versions. THEY know when a release should be done and when a release is stable or not. 4) Now I created all the Metacello configurations for the PharoDev image and I took me a lot of time. Because I am not the developer of any of those projects. So, I need to understand the dependencies, the order, the versions, etc. But why ??? If Seaside people have already done that, don't duplicate efforts. 5) The instability of PharoWeb images give to our public a bad impression. We waste all of out efforts of Pharo in that image. 6) The idea of Pharo is to be the vehicle. And that's exactly the Pharo role in the Seaside images. We don't need to build PharoWeb images. Even more, do we build PharoGlass images ? N. Why not ? Because Dale already prepare them and as HE knows much more about Glass than us, his images are better for Glass. 7) Tracking and managing issues always take time. Even analyzing a bug, say we won't fix and close it. With PharoWeb images we are having those kind of issues. 8) Our resources are limited. Why not to use them in more important stuff ? For example, building a better and more robust Dev image? Here is my proposal: 1) Completely remove the idea of PharoWeb image. Remove the links from the website and do not create Web images any more. 2) In http://www.pharo-project.org/pharo-download add a description explaining that now Seaside images are based in Pharo, so you can directly download that image. We can even explain a bit about seaside, and even if you want you can put a href called PharoWeb which links to the seaside image. However, I would rather call it PharoSeaside. 3) Tomorrow we can have AidaWeb images based in pharo (please Janko!!) so we can just do the same and put the link to those images. 4) You may notice that Seaside images are a bit different than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more similar to our Dev images, just run that script. So...what do you think? I would really like to hear your opinion about this. Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com What is more important: To be happy, or to make happy? ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About moving tmp closer their use
My own preference is a balance between being readable and efficient. At first, i care above anything to make my code readable. And I think that, being properly formatted, declaring temps in blocks scope not makes code less readable. Also, i think that keeping variables close to desired scope, will instead could help improving code readability. But i must say, we should learn teach developers to write code short consise, or at least attempt to (following a well known smalltalk practice - 1/2 lines per method). Then we wouldn't need to choose, what way of declaring temps is better ;) 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: Hi guys in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete system so that |temp| declaration would be at the scope where they are used. This is not clear that this is an optimisation but I like the fact that temp are defined at the right place. Now it may lead to code that is a bit less readable in the sense that your temps are not systematically listed at the beginning of the method but occasionally in the closures that use them. From my hackish lisping state of mind I like it now what do you prefer? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
2010/1/4 Schwab,Wilhelm K bsch...@anest.ufl.edu We certainly don't need the web images, but I would like to see them stay to help with testing. If we are building them with unstable versions of Seaside, that is a problem with the process (loading the wrong stuff) not the concept/service (providing a Seaside-ready version of Pharo for testing). We just finished designing a beta program, at least three of volunteers indicated a preference for the web image. Bill: On the contrary: I don't want to have beta testers in PharoWeb and then others in Seaside one click images (which are also based in Pharo). My idea is the contrary: JOIN FORCES. If people who were now using PharoWeb image, start to use Seaside images, they will also help to test and debugs. A lot of issues reported in those images in Seaside were actually Pharo issues. In addition, is VERY uncommon that an issue of the IDE appears in PharoWeb but not in PharoDev. So, most of the issues in PharoWeb that are not present in PharoDev may be related to Seaside, and even probably, because we are using worng version of the packages. Cheers Mariano Bill -- *From:* pharo-project-boun...@lists.gforge.inria.fr [mailto: pharo-project-boun...@lists.gforge.inria.fr] *On Behalf Of *Mariano Martinez Peck *Sent:* Monday, January 04, 2010 3:25 AM *To:* Pharo Development *Subject:* [Pharo-project] What about killing PharoWeb images? Please, don't say NO! immediately. Read the mail carefully, take a deep breath and think cold. After working a couple of weeks in the Metacello configurations and now with Damien's scripts to build Dev and Web images, I came to the question: Do we really need a PharoWeb image? I will give just my opinions of why having PharoWeb images is not a good idea anymore 1) First of all, I don't like the PharoWeb name. Because it is not Web in general, it is seaside. So, in my opinion, a better name would be PharoSeaside. Maybe even new comers may think that the only alternative is seaside. You know I have nothing against Seaside and that I even use it several times. I would like to see AidaWeb images based in Pharo too. 2) Why to still have PharoWeb images if now Seaside images (at least the one click) are based in seaside ? In addition, when I develop in Seaside, I use Seaside images, not PharoWeb, and I think most people do the same. 3) Seaside images (or Lukas images for seaside) are MUCH more stable than the PharoWeb images. Why? Several reasons: 3.a) THEY know the dependencies of the packages, the versions, how to set up, the order of load, etc, NOT us. THEY are the experts in seaside, not us. 3.b) THEY really test their images before make then public. 3.c) We are force to release one release per month which has no sense. How says that Seaside is released once a month? That's bad because it means we are usually taking unstable versions. THEY know when a release should be done and when a release is stable or not. 4) Now I created all the Metacello configurations for the PharoDev image and I took me a lot of time. Because I am not the developer of any of those projects. So, I need to understand the dependencies, the order, the versions, etc. But why ??? If Seaside people have already done that, don't duplicate efforts. 5) The instability of PharoWeb images give to our public a bad impression. We waste all of out efforts of Pharo in that image. 6) The idea of Pharo is to be the vehicle. And that's exactly the Pharo role in the Seaside images. We don't need to build PharoWeb images. Even more, do we build PharoGlass images ? N. Why not ? Because Dale already prepare them and as HE knows much more about Glass than us, his images are better for Glass. 7) Tracking and managing issues always take time. Even analyzing a bug, say we won't fix and close it. With PharoWeb images we are having those kind of issues. 8) Our resources are limited. Why not to use them in more important stuff ? For example, building a better and more robust Dev image? Here is my proposal: 1) Completely remove the idea of PharoWeb image. Remove the links from the website and do not create Web images any more. 2) In http://www.pharo-project.org/pharo-download add a description explaining that now Seaside images are based in Pharo, so you can directly download that image. We can even explain a bit about seaside, and even if you want you can put a href called PharoWeb which links to the seaside image. However, I would rather call it PharoSeaside. 3) Tomorrow we can have AidaWeb images based in pharo (please Janko!!) so we can just do the same and put the link to those images. 4) You may notice that Seaside images are a bit different than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be
Re: [Pharo-project] 64 bit images (was Re: [squeak-dev] The Trunk: Collections-dtl.268.mcz)
excellent On Jan 4, 2010, at 1:44 PM, Laval Jannik wrote: Yes, but the changeset build the fix in SystemDictionary, In a previous discussion, we decide to create an instance variable in SmalltalkImage and to put methods in SmalltalkImage too. Cheers, Jannik On Jan 4, 2010, at 13:35 , Stéphane Ducasse wrote: Jannik did you check the changeset in the mantis bug report? Stef On Jan 4, 2010, at 10:53 AM, Laval Jannik wrote: Hi, I made a new version of the system-tracer (in attachment). It works fine with the latest pharo version. For wordSize, we decide to create a instance variable in SmalltalkImage, which is initialized at startup. The method initialPC is: --- initialPC Answer the program counter for the receiver's first bytecode. ^ (self numLiterals + 1) * SmalltalkImage current wordSize + 1 --- The fix will be integrated in Pharo soon. It is also in attachment. addWordSizeInSystemDictionary.1.csSystem-Tracing-forPharo.cs Cheers On Jan 3, 2010, at 06:46 , John M McIntosh wrote: Ok, well I was hoping that Laval Jannik would review the changes/solution in http://bugs.squeak.org/view.php?id=7430 then update his original System-Tracing.2forPharo3.cs Then test to confirm we can build a 64bit image from the current Pharo image On 2010-01-02, at 6:46 PM, David T. Lewis wrote: John, one additional note. The SystemTracer changesets currently in circulation have an obsolete implementation of SystemDictionarywordSize.The original 64-bit Squeak used vmParameterAt: 27 for the VM to answer its word size, but this was later changed to vmParameter at: 40. This is the reason that the original dist3 64-bit image does not work on current VMs. You will want to revert #wordSize back to a current version so that it uses vmParameter at: 40. This issue will go away when we implement the cached #wordSize fixes discussed separately (http://bugs.squeak.org/view.php?id=7430), but I wanted to mention it because I spotted the obsolete method in the System-Tracing2forPharo.cs change set. -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === --- Jannik Laval --- ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
2010/1/4 Schwab,Wilhelm K bsch...@anest.ufl.edu: We certainly don't need the web images, but I would like to see them stay to help with testing. If we are building them with unstable versions of Seaside, that is a problem with the process (loading the wrong stuff) not the concept/service (providing a Seaside-ready version of Pharo for testing). We just finished designing a beta program, at least three of volunteers indicated a preference for the web image. Bill 1. *We* (who sitting here for a while), certainly don't need web images. 2. Newcomers, or entry-level youngsters, definitely will prefer a ready-to-use solutions, which easy to install, run play with. So, +1 for keeping web images. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Does someone know why Nile is in Dev images?
Ok... The good news is that this is a community :) Sometimes the community thinks as you do and sometimes not. This is life ;) I will put it in the ConfigurationOfPharo for the Dev then. Cheers Mariano 2010/1/3 Schwab,Wilhelm K bsch...@anest.ufl.edu Mariano, You _like_ the new inspector :) Can't stand it myself. If I want that kind of view, I use the explorer. Selecting the standard toolset (so far at least) makes it go away, so I'm happy. One thing that I miss is the diving inspector that started in VW (IIRC) and was ported to Dolphin. Nile causes me no trouble, and I am glad to see movement away from the Squeak streams. We will not be able to rid ourselves of the latter w/o elevating Nile to being a part of the system. Your point about putting it in the core is well-taken, but I think having it in the dev/web images is a good thing because it should help drive Moose and other groups to dev as opposed to the core. Given our obvious need to test before releasing the dev/web images, anything that promotes their use is helpful. Bill -- *From:* pharo-project-boun...@lists.gforge.inria.fr [mailto: pharo-project-boun...@lists.gforge.inria.fr] *On Behalf Of *Mariano Martinez Peck *Sent:* Sunday, January 03, 2010 7:03 AM *To:* Pharo-project@lists.gforge.inria.fr *Subject:* Re: [Pharo-project] Does someone know why Nile is in Dev images? Sorry Stef but I disagree. PLEASE don't misunderstand me. I know a lot of very good people have worked and is still working in Nile project. So, I am sure it is an excellent product. However, I don't think it should be in Dev image. Dev image is for Developers. So, we put tools like NewInspector, RoelTyper, E and OCompletion, Refactoring, etc. But why Nile ? I am not agree this is neither a way to push Nile to be used. It is no difference if you already have the code in the image or not, it is just one click of difference (as you have the Nile-All). Even if it where the case, I think it should be in Core image. The way to push a project to be used is to write documentation, tutorials, show the benefits over other implementationsand so on. If Moose use it, ok, put it as a dependency. Now you have a Metacello configuration for Moose :) I mean, in SqueakDBX we use FFI and we don't put in the image. Seaside uses Slime and it is not in the image. Just my opinion. I hope no one feels offended. What others think about this ? Cheers Mariano On Sun, Jan 3, 2010 at 11:02 AM, Stéphane Ducasse stephane.duca...@inria.fr wrote: Nile is in dev because it should be progressively use to replace existing streams. For example in Moose some important collection extensions depend on it. Does another package of the dev image depends on Nile? If not, I don't understand why it is part of the dev image. I see it as any other external package but not a dev tool that should be included. Thanks Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
On Mon, Jan 4, 2010 at 2:01 PM, Igor Stasenko siguc...@gmail.com wrote: 2010/1/4 Schwab,Wilhelm K bsch...@anest.ufl.edu: We certainly don't need the web images, but I would like to see them stay to help with testing. If we are building them with unstable versions of Seaside, that is a problem with the process (loading the wrong stuff) not the concept/service (providing a Seaside-ready version of Pharo for testing). We just finished designing a beta program, at least three of volunteers indicated a preference for the web image. Bill 1. *We* (who sitting here for a while), certainly don't need web images. 2. Newcomers, or entry-level youngsters, definitely will prefer a ready-to-use solutions, which easy to install, run play with. So, +1 for keeping web images. But Igor, there is nothing easier than a double click. And seaside one click is just a double click no matter in what OS you are. They are MUCH more easier for new commers than a PharoWeb image where they have to download the VM, the sources and the image. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About moving tmp closer their use
I remember the first time I ever tried Squeak all those years ago, this was the first thing that bit me - not being able to declare temporary variables within the blocks that use them. I was so used to doing that from VisualAge. So, I vote in favour of the change :-) On Mon, Jan 4, 2010 at 1:58 PM, Igor Stasenko siguc...@gmail.com wrote: My own preference is a balance between being readable and efficient. At first, i care above anything to make my code readable. And I think that, being properly formatted, declaring temps in blocks scope not makes code less readable. Also, i think that keeping variables close to desired scope, will instead could help improving code readability. But i must say, we should learn teach developers to write code short consise, or at least attempt to (following a well known smalltalk practice - 1/2 lines per method). Then we wouldn't need to choose, what way of declaring temps is better ;) 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: Hi guys in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete system so that |temp| declaration would be at the scope where they are used. This is not clear that this is an optimisation but I like the fact that temp are defined at the right place. Now it may lead to code that is a bit less readable in the sense that your temps are not systematically listed at the beginning of the method but occasionally in the closures that use them. From my hackish lisping state of mind I like it now what do you prefer? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About moving tmp closer their use
Stéphane Ducasse a écrit : Hi guys in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete system so that |temp| declaration would be at the scope where they are used. This is not clear that this is an optimisation but I like the fact that temp are defined at the right place. Now it may lead to code that is a bit less readable in the sense that your temps are not systematically listed at the beginning of the method but occasionally in the closures that use them. From my hackish lisping state of mind I like it now what do you prefer? Yes, I always prefer to see variable declarations in the scope where they are used Alain Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Can't use Enter key to select notifier action
Sorry for delay, away for xmas! Having played around with a few OSes perhaps we should allow the enter key when a button has keyboard focus. For dialogs, where no button has keyboard focus, the default button should be activated (barring any specifc use of enter in the morph that has keyboard focus). Regards, Gary - Original Message - From: Mariano Martinez Peck To: Pharo-project@lists.gforge.inria.fr Sent: Sunday, December 20, 2009 5:40 PM Subject: Re: [Pharo-project] Can't use Enter key to select notifier action 2009/12/20 danklein dani...@danielk.us When a notifier pops up, you can tab (or shift-tab) to the Proceed/Abandon/Debug/Create buttons at the top of the window. However, when the one you want is highlighted, I would like to be able to just press the to execute it, but you have to actually click on it. Is there a configuration setting to affect this behavior? It works with the space key, but not to the enter key. I remember a similar issue that Gary solve. It let us use the enter key instead of the space key in some cases, for example when you save a method with an undeclared variable and it gives you the optionsI couldn't find it in my mails gary do you remember ? Cheers, Mariano View this message in context: Can't use key to select notifier action Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
On Jan 4, 2010, at 2:45 57AM, Levente Uzonyi wrote: On Wed, 30 Dec 2009, Stéphane Ducasse wrote: BIG THANKS igor!!! 11127 - - Issue 1690: New Method Trailer part 7 (cs 9) There are still some issues. Some methods (for example TPureBehavior #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) Levente CompiledMethodstoreOn: also needs to be updated, (Compiler evaluate: aCompiledMethod storeString) does not reconstruct the original trailer. Caught by ArrayTest testComplexIsSelfEvaluating, of all places :) Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Can't use Enter key to select notifier action
You are the boss for that. Let us know. On Jan 4, 2010, at 2:26 PM, Gary Chambers wrote: Sorry for delay, away for xmas! Having played around with a few OSes perhaps we should allow the enter key when a button has keyboard focus. For dialogs, where no button has keyboard focus, the default button should be activated (barring any specifc use of enter in the morph that has keyboard focus). Regards, Gary - Original Message - From: Mariano Martinez Peck To: Pharo-project@lists.gforge.inria.fr Sent: Sunday, December 20, 2009 5:40 PM Subject: Re: [Pharo-project] Can't use Enter key to select notifier action 2009/12/20 danklein dani...@danielk.us When a notifier pops up, you can tab (or shift-tab) to the Proceed/Abandon/Debug/Create buttons at the top of the window. However, when the one you want is highlighted, I would like to be able to just press the to execute it, but you have to actually click on it. Is there a configuration setting to affect this behavior? It works with the space key, but not to the enter key. I remember a similar issue that Gary solve. It let us use the enter key instead of the space key in some cases, for example when you save a method with an undeclared variable and it gives you the optionsI couldn't find it in my mails gary do you remember ? Cheers, Mariano View this message in context: Can't use key to select notifier action Sent from the Pharo Smalltalk mailing list archive at Nabble.com. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] About moving tmp closer their use
On Jan 4, 2010, at 2:05 PM, Peter Hugosson-Miller wrote: I remember the first time I ever tried Squeak all those years ago, this was the first thing that bit me - not being able to declare temporary variables within the blocks that use them. I was so used to doing that from VisualAge. Me too :) Stef So, I vote in favour of the change :-) On Mon, Jan 4, 2010 at 1:58 PM, Igor Stasenko siguc...@gmail.com wrote: My own preference is a balance between being readable and efficient. At first, i care above anything to make my code readable. And I think that, being properly formatted, declaring temps in blocks scope not makes code less readable. Also, i think that keeping variables close to desired scope, will instead could help improving code readability. But i must say, we should learn teach developers to write code short consise, or at least attempt to (following a well known smalltalk practice - 1/2 lines per method). Then we wouldn't need to choose, what way of declaring temps is better ;) 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: Hi guys in squeak a week ago nicolas pushed a cool (from my taste) changes that refactored the complete system so that |temp| declaration would be at the scope where they are used. This is not clear that this is an optimisation but I like the fact that temp are defined at the right place. Now it may lead to code that is a bit less readable in the sense that your temps are not systematically listed at the beginning of the method but occasionally in the closures that use them. From my hackish lisping state of mind I like it now what do you prefer? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Cheers, Peter ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
Igor what is the new way of doing methodAndNode := self compile: source classified: nil notifying: nil trailer: #(0 0 0 0) ifFail: [^nil]. in addTraitSelector: aSymbol withMethod: aCompiledMethod Add aMethod with selector aSymbol to my methodDict. aMethod must not be defined locally. | source methodAndNode | self assert: [(self includesLocalSelector: aSymbol) not]. self ensureLocalSelectors. source := aCompiledMethod getSourceReplacingSelectorWith: aSymbol. methodAndNode := self compile: source classified: nil notifying: nil trailer: #(0 0 0 0) ifFail: [^nil]. methodAndNode method putSource: source fromParseNode: methodAndNode node inFile: 2 withPreamble: [:f | f cr; nextPut: $!; nextChunkPut: 'Trait method'; cr]. self basicAddSelector: aSymbol withMethod: methodAndNode method In squeak and pharo the following code is used and I was wondering if the API (explicit ue of trailer: or bytes (maybe a trailerObject is passed - I did not check) is good. I thought that this was the job of the CompilerMethodTrailer to know the bytes. compile: code classified: category notifying: requestor trailer: bytes ifFail: failBlock Compile code without logging the source in the changes file | methodNode | methodNode := self compilerClass new compile: code in: self classified: category notifying: requestor ifFail: failBlock. ^ CompiledMethodWithNode generateMethodFromNode: methodNode trailer: bytes. CompiledMethodWithNodegenerateMethodFromNode: aMethodNode trailer: bytes ^ self method: (aMethodNode generate: bytes) node: aMethodNode. Stef hmm. i thought i fixed this one. 2010/1/4 Levente Uzonyi le...@elte.hu: On Wed, 30 Dec 2009, Stéphane Ducasse wrote: BIG THANKS igor!!! 11127 - - Issue 1690: New Method Trailer part 7 (cs 9) There are still some issues. Some methods (for example TPureBehavior #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) Levente ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
methodAndNode := self compile: source classified: nil notifying: nil trailer: self defaultMethodTrailer ifFail: [^nil]. ?? On Jan 4, 2010, at 3:19 PM, Stéphane Ducasse wrote: Igor what is the new way of doing methodAndNode := self compile: source classified: nil notifying: nil trailer: #(0 0 0 0) ifFail: [^nil]. in addTraitSelector: aSymbol withMethod: aCompiledMethod Add aMethod with selector aSymbol to my methodDict. aMethod must not be defined locally. | source methodAndNode | self assert: [(self includesLocalSelector: aSymbol) not]. self ensureLocalSelectors. source := aCompiledMethod getSourceReplacingSelectorWith: aSymbol. methodAndNode := self compile: source classified: nil notifying: nil trailer: #(0 0 0 0) ifFail: [^nil]. methodAndNode method putSource: source fromParseNode: methodAndNode node inFile: 2 withPreamble: [:f | f cr; nextPut: $!; nextChunkPut: 'Trait method'; cr]. self basicAddSelector: aSymbol withMethod: methodAndNode method In squeak and pharo the following code is used and I was wondering if the API (explicit ue of trailer: or bytes (maybe a trailerObject is passed - I did not check) is good. I thought that this was the job of the CompilerMethodTrailer to know the bytes. compile: code classified: category notifying: requestor trailer: bytes ifFail: failBlock Compile code without logging the source in the changes file | methodNode | methodNode := self compilerClass new compile: code in: self classified: category notifying: requestor ifFail: failBlock. ^ CompiledMethodWithNode generateMethodFromNode: methodNode trailer: bytes. CompiledMethodWithNodegenerateMethodFromNode: aMethodNode trailer: bytes ^ self method: (aMethodNode generate: bytes) node: aMethodNode. Stef hmm. i thought i fixed this one. 2010/1/4 Levente Uzonyi le...@elte.hu: On Wed, 30 Dec 2009, Stéphane Ducasse wrote: BIG THANKS igor!!! 11127 - - Issue 1690: New Method Trailer part 7 (cs 9) There are still some issues. Some methods (for example TPureBehavior #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) Levente ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: methodAndNode := self compile: source classified: nil notifying: nil trailer: self defaultMethodTrailer ifFail: [^nil]. ?? yup. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: Igor what is the new way of doing methodAndNode := self compile: source classified: nil notifying: nil trailer: #(0 0 0 0) ifFail: [^nil]. in addTraitSelector: aSymbol withMethod: aCompiledMethod Add aMethod with selector aSymbol to my methodDict. aMethod must not be defined locally. | source methodAndNode | self assert: [(self includesLocalSelector: aSymbol) not]. self ensureLocalSelectors. source := aCompiledMethod getSourceReplacingSelectorWith: aSymbol. methodAndNode := self compile: source classified: nil notifying: nil trailer: #(0 0 0 0) ifFail: [^nil]. methodAndNode method putSource: source fromParseNode: methodAndNode node inFile: 2 withPreamble: [:f | f cr; nextPut: $!; nextChunkPut: 'Trait method'; cr]. self basicAddSelector: aSymbol withMethod: methodAndNode method In squeak and pharo the following code is used and I was wondering if the API (explicit ue of trailer: or bytes (maybe a trailerObject is passed - I did not check) is good. I thought that this was the job of the CompilerMethodTrailer to know the bytes. compile: code classified: category notifying: requestor trailer: bytes ifFail: failBlock Compile code without logging the source in the changes file | methodNode | methodNode := self compilerClass new compile: code in: self classified: category notifying: requestor ifFail: failBlock. ^ CompiledMethodWithNode generateMethodFromNode: methodNode trailer: bytes. CompiledMethodWithNodegenerateMethodFromNode: aMethodNode trailer: bytes ^ self method: (aMethodNode generate: bytes) node: aMethodNode. Stef sorry for naming confusion . It deserves a proper 'trailer' name in those methods instead of 'bytes'. And yes, there should be no bytes anymore.. so, anywhere you see them - you should nuke em. hmm. i thought i fixed this one. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] [ANN] SystemTracer on SqueakSource
Hi David, I cannot load SystemTracing-dtl.11 in a pharoCore1.1. There is a syntax error in SystemTracingheadersFor:withHash:numFields: Is there another way to load the code ? Thanks, Jannik On Jan 3, 2010, at 18:21 , David T. Lewis wrote: I have created a SqueakSource project called SystemTracing to serve as a repository for the various SystemTracer implementations that have appeared in and around Squeak images since Squeak 1.22. The intent is to make these implementations loadable in modern images, and to provide a Monticello repository for new development. MCHttpRepository location: 'http://www.squeaksource.com/SystemTracing' user: 'squeak' password: 'squeak' All classes and package extension methods have been recategoried to SystemTracing but are otherwise unmodified to the extent possible. The recategorizing was done by hand-editing the original change sets. The archive includes historical versions that appeared in early Squeak images, as well as loadable versions of the SystemTracer2 that is catalogued on SqueakMap. There is an entry for the SystemTracer64 that was used to produce the first 64-bit Squeak image, and recent updates that will enable 64-bit images to be traced from modern Squeak and Pharo images (there is more work to be done here). Developer access is provided for Stephen Pair, John M McIntosh, Andreas Raab, Eliot Miranda, Jannik Laval, Ian Piumarta. If anyone else should be added as developer, please speak up. All future contributions to this archive are required to be MIT licensed. Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
Hi Andreas, This may be the stupid question of the day, but can someone explain to me why we aren't just hard-wiring the word size (say in a CompiledMethod class var or so)? It's not like the primitive would *ever* return anything else unless you grind the image through SystemTracer, the value of wordSize is initialized only one time, If wordSize is nil, it takes the value of the primitive 40. and if you do that, SystemTracer can simply update those values. Yes, it does. SystemTracer pushes the value of primitive 40 in wordSize. It seems silly to build caches, primitives, cache invalidation for a value which will never ever change dynamically. Besides I think the cache invalidation might be wrong - The cache is synchronized with the VM only one time after the creation of the image, I think it is better than a hard-writing value. how do you know that initialPC or other word size related methods aren't sent before the startUp method is executed? startUp method is the first method executed at the startup, no ? But in SystemTracer, the value is initialized in clonePreStartup method. So there is no problem with potential method calls before startUp. Cheers, - Andreas Cheers, --- Jannik Laval --- ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Notifications of windows opening/closing/focus
Hi How do you get notified of windows opening, closing, or getting focus in Pharo? Is there some announcements or some older events? -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Notifications of windows opening/closing/focus
Nothing like that currently or previously AFAIK. Regards, Gary - Original Message - From: Simon Denier simon.den...@inria.fr To: Pharo Development pharo-project@lists.gforge.inria.fr Sent: Monday, January 04, 2010 4:00 PM Subject: [Pharo-project] Notifications of windows opening/closing/focus Hi How do you get notified of windows opening, closing, or getting focus in Pharo? Is there some announcements or some older events? -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
Em 04/01/2010 06:24, Mariano Martinez Peck marianop...@gmail.com escreveu: Please, don't say NO! immediately. Read the mail carefully, take a deep breath and think cold. After working a couple of weeks in the Metacello configurations and now with Damien's scripts to build Dev and Web images, I came to the question: Do we really need a PharoWeb image? I will give just my opinions of why having PharoWeb images is not a good idea anymore [snipped] On the whole I appreciate and agree with the reasoning. Here is my proposal: 1) Completely remove the idea of PharoWeb image. Remove the links from the website and do not create Web images any more. +1 2) In http://www.pharo-project.org/pharo-download add a description explaining that now Seaside images are based in Pharo, so you can directly download that image. We can even explain a bit about seaside, and even if you want you can put a href called PharoWeb which links to the seaside image. However, I would rather call it PharoSeaside. I think here we have to work hard to stress this fact since IIUC the /pièce de résistance/ for Pharo is having all production work done by Seaside. 3) Tomorrow we can have AidaWeb images based in pharo (please Janko!!) so we can just do the same and put the link to those images. While I'm fond of the idea on having AidaWeb very soon as possible, I also think we should put ourselves in Janko's shoes and understand that he'll need to master Metacelllo to arrive at the packaging. . . 4) You may notice that Seaside images are a bit different than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more similar to our Dev images, just run that script. I would postpone the publishing of these kind of scripts for a much more stable Pharo and Metacello (or packaging solution ensuing), otherwise you'll have the same work as testing the scripts means creating and testing the packages!! So...what do you think? I would really like to hear your opinion about this. my 0.0199 -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Notifications of windows opening/closing/focus
How do you get notified of windows opening, closing, or getting focus in Pharo? Is there some announcements or some older events? Hi Simon, I did something like this for Mondrian. It is based on announcement. For multiple reasons, I haven't got the time to push it into the mainstream. Load Mondrian, and you will find the class: MOMorphicExtensionInstaller When this class is loaded, it installs a changeset defined in a class- side method. Have a look at the class MorphicWindowNotificationTest to see how to use it. I have been using this extension for some time, it is pretty harmless. Maybe I can put it in a dedicated Monticello repository... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
If the method is installed, I would only store a reference (MyClass#myMethod). That's what is done on Class, they are stored by reference: String streamContents: [:strm | Array storeOn: strm] - 'Array' Otherwise, if the method is not installed, I would not store a trailer pointing to some source somewhere indeed, but why not a trailer encoding compressed temp vars or direct source... Anyway, is the trailer a relevant point of comparison ? Nicolas 2010/1/4 Igor Stasenko siguc...@gmail.com: 2010/1/4 Henrik Johansen henrik.s.johan...@veloxit.no: On Jan 4, 2010, at 2:45 57AM, Levente Uzonyi wrote: On Wed, 30 Dec 2009, Stéphane Ducasse wrote: BIG THANKS igor!!! 11127 - - Issue 1690: New Method Trailer part 7 (cs 9) There are still some issues. Some methods (for example TPureBehavior #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) Levente CompiledMethodstoreOn: also needs to be updated, (Compiler evaluate: aCompiledMethod storeString) does not reconstruct the original trailer. The only way how you should be allowed to reconstruct a compiled method from string, is compilation, otherwise you risking crashing the system. But compilation _always_ creating a new artifact - a compiled method , and picking an appropriate trailer for it. The way, how CompiledMethodstoreOn: does, seems an abuse, as to me, because i won't bet on safety of keeping a methods in such format, even for existing images. For instance, you could store a method , then condense changes, and then if you attempt to restore it, you will end up with having a sourcePointer pointing to invalid .changes file location. So, i rather prefer seeing this method implemented like following: CompiledMethodstoreOn: aStream ^ self shoulNotBeImplemented Caught by ArrayTest testComplexIsSelfEvaluating, of all places :) Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
2010/1/4 Nicolas Cellier nicolas.cellier.aka.n...@gmail.com: If the method is installed, I would only store a reference (MyClass#myMethod). +1 That's what is done on Class, they are stored by reference: String streamContents: [:strm | Array storeOn: strm] - 'Array' Otherwise, if the method is not installed, I would not store a trailer pointing to some source somewhere indeed, but why not a trailer encoding compressed temp vars or direct source... because you could store the source code instead. Anyway, is the trailer a relevant point of comparison ? i am against storing the compiled method in any other form than source code, except referential form, like 'Array #at: ' , you mentioned. So, either way, after restoring you getting an already existing CompiledMethod instance, or fresh one, which just compiled from stored source code. We just should not allow a potentially dangerous ways of manipulating a binary data, stored in compiled method, including trailer and bytecodes. Because they are subject of change (if we observe them over long period ;) Nicolas 2010/1/4 Igor Stasenko siguc...@gmail.com: 2010/1/4 Henrik Johansen henrik.s.johan...@veloxit.no: On Jan 4, 2010, at 2:45 57AM, Levente Uzonyi wrote: On Wed, 30 Dec 2009, Stéphane Ducasse wrote: BIG THANKS igor!!! 11127 - - Issue 1690: New Method Trailer part 7 (cs 9) There are still some issues. Some methods (for example TPureBehavior #addTraitSelector:withMethod:) still use the old trailer bytes #(0 0 0 0). These should be removed asap (I had to make some surgery with #become: to compile the new version.) Levente CompiledMethodstoreOn: also needs to be updated, (Compiler evaluate: aCompiledMethod storeString) does not reconstruct the original trailer. The only way how you should be allowed to reconstruct a compiled method from string, is compilation, otherwise you risking crashing the system. But compilation _always_ creating a new artifact - a compiled method , and picking an appropriate trailer for it. The way, how CompiledMethodstoreOn: does, seems an abuse, as to me, because i won't bet on safety of keeping a methods in such format, even for existing images. For instance, you could store a method , then condense changes, and then if you attempt to restore it, you will end up with having a sourcePointer pointing to invalid .changes file location. So, i rather prefer seeing this method implemented like following: CompiledMethodstoreOn: aStream ^ self shoulNotBeImplemented Caught by ArrayTest testComplexIsSelfEvaluating, of all places :) Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: Mac VM 5.2.b2 ships
On Mon, Jan 4, 2010 at 3:33 PM, Simon Michael si...@joyful.com wrote: John, thanks for the more precise directions (yesterday I gave up in confusion). To encourage other mac users to switch, here's the exact url: ftp://ftp.smalltalkconsulting.com/experimental/64bit/32bitImage*64bitVM/Squeak%2064-32%205.2b2.app.zip I've made this my default vm and so far so good (I can open and operate a bunch of my images). But at the same time??? I cannot open more than one image at the same time with this version. When I try to open the second one, it is not open and even more, no matter what OS windows I have focus, it goes to the first image. It is like if it thinks that it has already opened the image. Cheers Mariano I'm looking forward to apple-Q, apple-H etc working. Thanks for the shiny new vm! -Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
On Mon, Jan 4, 2010 at 5:22 PM, csra...@bol.com.br wrote: Em 04/01/2010 06:24, Mariano Martinez Peck marianop...@gmail.com escreveu: Please, don't say NO! immediately. Read the mail carefully, take a deep breath and think cold. After working a couple of weeks in the Metacello configurations and now with Damien's scripts to build Dev and Web images, I came to the question: Do we really need a PharoWeb image? I will give just my opinions of why having PharoWeb images is not a good idea anymore [snipped] On the whole I appreciate and agree with the reasoning. Here is my proposal: 1) Completely remove the idea of PharoWeb image. Remove the links from the website and do not create Web images any more. +1 2) In http://www.pharo-project.org/pharo-download add a description explaining that now Seaside images are based in Pharo, so you can directly download that image. We can even explain a bit about seaside, and even if you want you can put a href called PharoWeb which links to the seaside image. However, I would rather call it PharoSeaside. I think here we have to work hard to stress this fact since IIUC the /pièce de résistance/ for Pharo is having all production work done by Seaside. I am not sure if I understood you correctly. Of course that supports Seaside is one of the most important task in Pharo, but not the only one. I don't know what do you mean with production, but I know few production application running in Pharo without Seaside. As Marcus or Gary for example. I really would like Pharo to be the vehicle for all of them: Seaside, AidaWeb, GemTools, Moose, etc. 3) Tomorrow we can have AidaWeb images based in pharo (please Janko!!) so we can just do the same and put the link to those images. While I'm fond of the idea on having AidaWeb very soon as possible, I also think we should put ourselves in Janko's shoes and understand that he'll need to master Metacelllo to arrive at the packaging. . . Yes, maybe. But that's not in our discussion. I mean, suppose I don't care how Janko builds his images, I really would like that to be also PharoWeb. So, it that case we just add one link more to our website: Pharo Web with Seaside , Pharo Web with AidaWeb , Pharo Client for Gemstone, etc... 4) You may notice that Seaside images are a bit different than our Dev images. This is mostly due to the preferences, the theme and maybe some tools (ECompeltion instead of OCompletion, etc..). So, what I suggest is to prepare a little script that can be downloadable and those people who want a Seaside image but more similar to our Dev images, just run that script. I would postpone the publishing of these kind of scripts for a much more stable Pharo and Metacello (or packaging solution ensuing), otherwise you'll have the same work as testing the scripts means creating and testing the packages!! Good point. If you want we can achieve that later. Even for 1.1. But at least, for the moment, for the newcomers, I doesn't cost anything a little script to at least set the preferences and theme we use in PharoDev (this has nothing to do with the Package Managment). Thanks for giving me your opinion Carlos. Cheers Mariano So...what do you think? I would really like to hear your opinion about this. my 0.0199 -- Cesar Rabak ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
Hi, I understand your comments, So: - i will put word size a class var, - this class var will be modify only by systemTracer Now I have a question: Why using Smalltalk wordSize whereas the vm parameter is getting by SmalltalkImage current ? Cheers, Jannik On Jan 4, 2010, at 17:39 , David T. Lewis wrote: On Mon, Jan 04, 2010 at 05:15:28PM +0100, Andreas Raab wrote: Hi Jannik - A couple of comments. First, If wordSize is a constant, put it into a class var. That's the best practice pattern for dealing with constants and I see no reason why one would opt to use an ivar for a value that never changes. See for example the EndianCache in SmalltalkImage and other use of constants throughout the system. As for caching, if I understand your description correctly, then system tracer is storing the correct value for the traced image. When the image starts, your cache code invalidates the known to be correct value which is later lazily filled in with the same value again. So what observable effect does your cache invalidation have? #startUp isn't the first method sent, not by a very long shot - in particular when you mess with the execution machinery you have to be aware that a method like #initialPC might be called before you ever get to the point where you invalidate that cache (I'm not sure if this can happen in this concrete case). In any case you should trace through the startup sequence to find out just how much other code is executed before getting there. John and/or Bert previously pointed out that there is no need to ever set the cached value from the image, so this would be done from a system tracer only (and yes this should have a comment). My recommendations would be to make WordSize a class variable, leave the lazy initialization in (it might be helpful during install etc) but add a nice comment explaining that only system tracer ever modifies that value when a 32/64 bit image is written. And leave out the pointless cache invalidation :-) I think that the change set on Mantis 7430 does what you describe. This puts the class variable in SystemDictionary in order to retain the current Smalltalk wordSize idiom, and uses the original Dan Ingalls #initialPC implementation from the dist3 64-bit image. It's a small change, so I'll copy it here: 'From Squeak3.10.2 of 16 December 2009 [latest update: #8496] on 18 December 2009 at 6:08:11 pm'! Change Set: Smalltalk-wordSize-dtl-M7430 Date: 18 December 2009 Author: David T. Lewis Cache Smalltalk wordSize in class var in SystemDictionary.. Update CompiledMethodinitialPC to use #wordSize. This is the method as implemented in the original 64-bit image (author di).! IdentityDictionary subclass: #SystemDictionary instanceVariableNames: 'cachedClassNames' classVariableNames: 'LastImageName LastQuitLogPosition LowSpaceProcess LowSpaceSemaphore MemoryHogs ShutDownList SpecialSelectors StartUpList StartupStamp SystemChanges WordSize' poolDictionaries: '' category: 'System-Support'! !CompiledMethod methodsFor: 'accessing' stamp: 'di 6/29/2004 12:28'! initialPC Answer the program counter for the receiver's first bytecode. ^ (self numLiterals + 1) * Smalltalk wordSize + 1 ! ! !SystemDictionary methodsFor: 'sources, change log' stamp: 'dtl 12/18/2009 00:32'! wordSize Answer the size (in bytes) of an object pointer. Smalltalk wordSize ^ WordSize ifNil: [WordSize := [SmalltalkImage current vmParameterAt: 40] on: Error do: [4]]! ! ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
- Lukas Renggli reng...@gmail.com wrote: | 4) Now I created all the Metacello configurations for the PharoDev | image and | I took me a lot of time. Because I am not the developer of any of | those | projects. So, I need to understand the dependencies, the order, the | versions, etc. But why ??? If Seaside people have already done that, | don't | duplicate efforts. | | There is a configuration for Seaside 3.0 (and probably also Seaside | 2.8). This was probably the first configuration every written. Ask | Dale. Yes Seaside3.0 was one of the original motivations behind Metacello:) There are Seaside3.0, Seaside2.8 and Pier (for Seaside2.8) configurations in the Metacello Repository and these were built based on information Lukas, so they should match pretty closely the web image content. I agree with the notion of one-click for ease of getting started with a particular framework/project. In the GLASS effort I've often outstripped the one-click images (and appliances) and run into support issues as a consequence. Once a developer is comfortable with the technology then they are likely to want to build their own image and if the one-click was built with a know configuration, then the developer has a reasonable chance of duplicating the code in his/her custom image. Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Building Pharo and Plugins for Mac OS X and Linux
Hi, I am new to Pharo and wonder if there is a step by step instruction on building Pharo for Mac OS X and Linux. I am working on a project that requires extension either through itself or via plugins. I have been seeing the mention of VMaker but can't find a good document about it. Thanks a lot for the help. David Li ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
- csra...@bol.com.br wrote: | 3) Tomorrow we can have AidaWeb images based in | pharo (please Janko!!) so we can just do the same and put the link | to those images. | | While I'm fond of the idea on having AidaWeb very soon as possible, I | also think we should put ourselves in Janko's shoes and understand | that he'll need to master Metacelllo to arrive at the packaging. . . Being able to easily load AidaWeb into GemStone was one of the other motivations for Metacello:) My todo list for Pharo, includes building a configuration for AidaWeb that will load AidaWeb into GLASS or Pharo (with feedback from Janko). I also plan incorporate Julian's work on Pier2 for Seaside3.0 into the Pier configuration (the current Pier configuration in MetacelloRepository is for Seaside2.8 only) Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
On Mon, Jan 4, 2010 at 7:14 PM, Dale Henrichs dale.henri...@gemstone.comwrote: - Lukas Renggli reng...@gmail.com wrote: | 4) Now I created all the Metacello configurations for the PharoDev | image and | I took me a lot of time. Because I am not the developer of any of | those | projects. So, I need to understand the dependencies, the order, the | versions, etc. But why ??? If Seaside people have already done that, | don't | duplicate efforts. | | There is a configuration for Seaside 3.0 (and probably also Seaside | 2.8). This was probably the first configuration every written. Ask | Dale. Yes Seaside3.0 was one of the original motivations behind Metacello:) There are Seaside3.0, Seaside2.8 and Pier (for Seaside2.8) configurations in the Metacello Repository and these were built based on information Lukas, so they should match pretty closely the web image content. This is really cool. And just because of this I think that we don't need the PharoWeb image, as you have the following options already: - Use metacello configuration by yourself. It is just one line of code and we can even explain in how to do it in the website. Even more, you can load that conf in a Pharo Dev, at that's all :) - Use Seaside one click - Use Lukas script. I agree with the notion of one-click for ease of getting started with a particular framework/project. In the GLASS effort I've often outstripped the one-click images (and appliances) and run into support issues as a consequence. Once a developer is comfortable with the technology then they are likely to want to build their own image and if the one-click was built with a know configuration, then the developer has a reasonable chance of duplicating the code in his/her custom image. Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Building Pharo and Plugins for Mac OS X and Linux
On Mon, Jan 4, 2010 at 7:19 PM, David Li tawe...@yahoo.com wrote: Hi, I am new to Pharo Hi and welcome! and wonder if there is a step by step instruction on building Pharo for Mac OS X and Linux. The only thing I am aware of is http://code.google.com/p/pharo/wiki/BuildingAVMOnPharo I am working on a project that requires extension either through itself what do you mean trought itself ? You just need to write a plugin or change the VM ? Why you need to tho that ? I ask because maybe someone has even a better solution or advice for you. Cheers Mariano or via plugins. I have been seeing the mention of VMaker but can't find a good document about it. Thanks a lot for the help. David Li ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about DependencyBrowser
Hi Mariano, Thank you for the feedback, I've updated the dependency browser package in SqueakSource, have a look for the latest package releases or evaluate the installation script again found in http://swikicaicyt.homeip.net/WebOpus/65 2009/12/26 Mariano Martinez Peck marianop...@gmail.com: On Sat, Dec 26, 2009 at 10:06 PM, Hernán Morales Durand hernan.mora...@gmail.com wrote: Hi Mariano! Nice to see you liked the Dependency Browser, let's clarify some points about it then, 2009/12/26 Mariano Martinez Peck marianop...@gmail.com: Hi Hernán: First let me say that this tool is really great and useful. It is helping me a lot to build the metacello configurations. Now, I have a couple of questions: 1) What do the colors mean ? (red, orange, etc). I read here http://cs.hernanmorales.com.ar/projects/dependencyBrowser/DBrowser-en.php but found nothing :( Colors were originally for idenfitying dependency types of external packages, but the package infos names aren't normalized, E.g. Normalized name = Collections, Un-normalized name = Collections-Strings, hence you will see a lot of false external packages colorized. Orange - Dependecy of class reference of external package, or class reference in un-normalized package name. Brown - Dependency of external package loose method, or loose method in un-normalized package name. Red - Dependency of inheritance, or inheritance in un-normalized package name. Blue - Dependency of a unsolved binding (like a class not present in the image). Thanks for the explanation. Now, as a good programmer you can reuse this explanation and put it in the website :) Ok, done. The official package home page is under http://www.caicyt.gov.ar/letodoc/paquetes-publicados Hey! I have more questions :) 3) Please, take a Pharo dev image and you will see that the package OCForOB for example, only depends on OmniBrowser and OB-Standard (using dependency browser). However, that package also depends on OCompletion I think. Look for example the method OBTextPanel createCompletionController (category ocforob) and you will see that it uses the class OController which is from the package OCompletionSo, shouldn't be OCompletion a dependency ? True, it is fixed now in the latest release. 4) There are certain packages that are not listed in the dependency browser. Examples OB-Standard, OB-Morphic, O2-Standard , etc...most of them (maybe all) seem to have the pattern XXX-YYY. Do you know what can be the problem here? Maybe something related to what you told me about normalized and un-normalized? I would really like to see these packages also. No, this was a missing line in the package listing. Fixed too. 5) Why there are some packages that have their self as dependency ? For example, take OmniBrowser and you will see that has a dependency OmniBrowser also (as Inheritance and Reference). May be useful to see internal dependencies? Cheers, Hernán ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
Ok I will fix that now. On Jan 4, 2010, at 3:27 PM, Igor Stasenko wrote: 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: methodAndNode := self compile: source classified: nil notifying: nil trailer: self defaultMethodTrailer ifFail: [^nil]. ?? yup. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Building Pharo and Plugins for Mac OS X and Linux
On Jan 5, 2010, at 3:24 AM, pharo-project-requ...@lists.gforge.inria.fr wrote: On Mon, Jan 4, 2010 at 7:19 PM, David Li tawe...@yahoo.com wrote: Hi, I am new to Pharo Hi and welcome! and wonder if there is a step by step instruction on building Pharo for Mac OS X and Linux. The only thing I am aware of is http://code.google.com/p/pharo/wiki/BuildingAVMOnPharo Thanks. I have come across that document as well. I kind of got stuck on figuring how how I can install VMMaker. I am working on a project that requires extension either through itself what do you mean trought itself ? You just need to write a plugin or change the VM ? Why you need to tho that ? I ask because maybe someone has even a better solution or advice for you. I am experimenting with Scratch and planning to integrate several native library into it. It seems that I can accomplish most of what I need via plugins. But it would be nice to get a clear pictures about how to build the VM and how the codes are structure in case I need to get in there. Cheers Mariano or via plugins. I have been seeing the mention of VMaker but can't find a good document about it. Thanks a lot for the help. David Li ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Thanks Danny :)
Am Montag, 4. Januar 2010 20:24:34 schrieb Stéphane Ducasse: Hi guys I can tell you that seeing this letter in my mailbox was ***really*** cool. Thanks danny this is a great license agreement. Stef Glad that you liked it, it is my favourite stamp, too. Danny ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
Igor when I try to recompile TPureBehavioraddTraitSelector: I get a DNU ArraycreateMethod:header: because the system uses itself when I add a method to a trait. This morning I did something and it worked but now I do not remember and I'm thinking how to turn around the problem. Do you have an idea? Stef methodAndNode := self compile: source classified: nil notifying: nil trailer: self defaultMethodTrailer ifFail: [^nil]. ?? yup. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Building Pharo and Plugins for Mac OS X and Linux
David check the squeak documentation on how to invoke external library with FFI. In pharo you have also alien (not tested on non intel - works on mac). You do not have to recompile the vm to invoke external library. You define methods with specific pragmas annotations and the plugin code can be invoked. One if these days we should write a better doc http://wiki.squeak.org/squeak/2426 http://www.is.titech.ac.jp/~ohshima/squeak/DShowVideo/index.html http://www.visoracle.com/squeak/faq/ffi-windows.html http://wiki.squeak.org/squeak/356 VMMaker is published on SqueakSource. May be people with more experience will comment. Stef On Jan 4, 2010, at 7:19 PM, David Li wrote: Hi, I am new to Pharo and wonder if there is a step by step instruction on building Pharo for Mac OS X and Linux. I am working on a project that requires extension either through itself or via plugins. I have been seeing the mention of VMaker but can't find a good document about it. Thanks a lot for the help. David Li ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
good! We need a good collection of good packages :) Being able to easily load AidaWeb into GemStone was one of the other motivations for Metacello:) My todo list for Pharo, includes building a configuration for AidaWeb that will load AidaWeb into GLASS or Pharo (with feedback from Janko). I also plan incorporate Julian's work on Pier2 for Seaside3.0 into the Pier configuration (the current Pier configuration in MetacelloRepository is for Seaside2.8 only) Dale ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
As a solution I was planning to redefine BehavioraddTraitSelector, TraitBehavioraddTraitSelector and then redefine it TPureBehavior then remove BehavioraddTraitSelector, TraitBehavioraddTraitSelector I imagine that it can work now I will try to see Stef On Jan 4, 2010, at 8:54 PM, Stéphane Ducasse wrote: Igor when I try to recompile TPureBehavioraddTraitSelector: I get a DNU ArraycreateMethod:header: because the system uses itself when I add a method to a trait. This morning I did something and it worked but now I do not remember and I'm thinking how to turn around the problem. Do you have an idea? Stef methodAndNode := self compile: source classified: nil notifying: nil trailer: self defaultMethodTrailer ifFail: [^nil]. ?? yup. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Thanks Danny :)
Which reminds me, I almost thought you'd made a sponsorship deal with the airport in Brest when I left ESUG, there was a shop there with lighthouses on _everything_! Though the Confit de Canard-boxes were tempting, I ended up just buying a deck of cards :) Cheers, Henry On 04.01.2010 20:51, Danny Chan wrote: Am Montag, 4. Januar 2010 20:24:34 schrieb Stéphane Ducasse: Hi guys I can tell you that seeing this letter in my mailbox was ***really*** cool. Thanks danny this is a great license agreement. Stef Glad that you liked it, it is my favourite stamp, too. Danny ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
On Mon, Jan 04, 2010 at 07:09:01PM +0100, Laval Jannik wrote: Hi, I understand your comments, So: - i will put word size a class var, - this class var will be modify only by systemTracer Now I have a question: Why using Smalltalk wordSize whereas the vm parameter is getting by SmalltalkImage current ? Hi Jannik, Different people may answer this question in different ways, because it is a matter of style and personal opinion. But it may help to know that earlier versions of Squeak had the vm parameter query in SystemDictionary (Smalltalk) rather than in SmalltalkImage. This was moved as part of a larger effort to reorganize SystemDictionary, which is a rather large class that has accumulated many functions over the years. As matter of function, it makes no difference either way. The part that is subject to opinion is whether it makes more sense for a person to say Smalltalk wordSize to refer to the size of a word in the object memory, or whether SmalltalkImage current wordSize is more meaningful. FWIW, my own opinion is that neither one is right, but Smalltalk wordSize is easier to remember. But no matter what approach is taken, you will be able to find someone who does not agree, so you should form your own opinion ;-) HTH, Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Thanks Danny :)
Which reminds me, I almost thought you'd made a sponsorship deal with the airport in Brest when I left ESUG, there was a shop there with lighthouses on _everything_! Apparently there are some lighthouses around brest. Did you ever see the movie on the tempest sent by samuel Though the Confit de Canard-boxes were tempting, I ended up just buying a deck of cards :) I would have taken the other with caramel au beurre sale. :) this brings me to the next point we could have a pharo goodies shop (like the one I did for Squeak and the squeakfoundation). With mugs and others. Does anybody interested in managing one at cafepress or better? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
Thank you Dave, Jannik On Jan 4, 2010, at 21:16 , David T. Lewis wrote: On Mon, Jan 04, 2010 at 07:09:01PM +0100, Laval Jannik wrote: Hi, I understand your comments, So: - i will put word size a class var, - this class var will be modify only by systemTracer Now I have a question: Why using Smalltalk wordSize whereas the vm parameter is getting by SmalltalkImage current ? Hi Jannik, Different people may answer this question in different ways, because it is a matter of style and personal opinion. But it may help to know that earlier versions of Squeak had the vm parameter query in SystemDictionary (Smalltalk) rather than in SmalltalkImage. This was moved as part of a larger effort to reorganize SystemDictionary, which is a rather large class that has accumulated many functions over the years. As matter of function, it makes no difference either way. The part that is subject to opinion is whether it makes more sense for a person to say Smalltalk wordSize to refer to the size of a word in the object memory, or whether SmalltalkImage current wordSize is more meaningful. FWIW, my own opinion is that neither one is right, but Smalltalk wordSize is easier to remember. But no matter what approach is taken, you will be able to find someone who does not agree, so you should form your own opinion ;-) HTH, Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about DependencyBrowser
On Mon, Jan 4, 2010 at 8:34 PM, Hernán Morales Durand hernan.mora...@gmail.com wrote: Hi Mariano, Thank you for the feedback, I've updated the dependency browser package in SqueakSource, have a look for the latest package releases or evaluate the installation script again found in http://swikicaicyt.homeip.net/WebOpus/65 Cool, thank you very much for your work. Hey! I have more questions :) 3) Please, take a Pharo dev image and you will see that the package OCForOB for example, only depends on OmniBrowser and OB-Standard (using dependency browser). However, that package also depends on OCompletion I think. Look for example the method OBTextPanel createCompletionController (category ocforob) and you will see that it uses the class OController which is from the package OCompletionSo, shouldn't be OCompletion a dependency ? True, it is fixed now in the latest release. Yes, cool. At this in this case It is fixed :) 4) There are certain packages that are not listed in the dependency browser. Examples OB-Standard, OB-Morphic, O2-Standard , etc...most of them (maybe all) seem to have the pattern XXX-YYY. Do you know what can be the problem here? Maybe something related to what you told me about normalized and un-normalized? I would really like to see these packages also. No, this was a missing line in the package listing. Fixed too. This is not working very well. When you select OB , Refectoring or any other which is not normalized and it brings the popup, even selecting something the popup brings again and again and againand I THINK the amount of times the pop up raises is the amount of packages you have as dependencies (the size of the collection of the right ;) Maybe this can help you to detect the problem. Another problem I have right now is this example: NewInspector. It extends the class ProtoObject with this method: ProtoObject niChildrenBlockForFixedFields (an extension for NewInspector). In that method, it uses the class TypeCollector which is form RoelTyper. However, RoelTyper is not shon as a dependency. Do you know what can be the problem ? Cheers Mariano ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
david I would really like to continue the cleaning of SystemDictionary because I do not like the current state of affair. Now we can either have a namespace class (with only namespace behavior) and a imageManagement class Now we could have one variable Smalltalk to point to either of it. but we will need another name. Now the point behind the current (which I do not like but live with it is that) it would be cool to be able to do from my image some query into your image). This was about thinking about that that SmalltalkImage current got birth. Now I would love to get some discussions about a way to - have a class management class = SystemDictionary but with clean contents and cool name = namespace? (which often people confused with having namespace at the language level and it not part of the proposal don't open the box please) - have a cool abstraction over image housekeeping - a cool abstraction about vm information so if you have ideas please let me know. Stef On Jan 4, 2010, at 9:16 PM, David T. Lewis wrote: On Mon, Jan 04, 2010 at 07:09:01PM +0100, Laval Jannik wrote: Hi, I understand your comments, So: - i will put word size a class var, - this class var will be modify only by systemTracer Now I have a question: Why using Smalltalk wordSize whereas the vm parameter is getting by SmalltalkImage current ? Hi Jannik, Different people may answer this question in different ways, because it is a matter of style and personal opinion. But it may help to know that earlier versions of Squeak had the vm parameter query in SystemDictionary (Smalltalk) rather than in SmalltalkImage. This was moved as part of a larger effort to reorganize SystemDictionary, which is a rather large class that has accumulated many functions over the years. As matter of function, it makes no difference either way. The part that is subject to opinion is whether it makes more sense for a person to say Smalltalk wordSize to refer to the size of a word in the object memory, or whether SmalltalkImage current wordSize is more meaningful. FWIW, my own opinion is that neither one is right, but Smalltalk wordSize is easier to remember. But no matter what approach is taken, you will be able to find someone who does not agree, so you should form your own opinion ;-) HTH, Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Thanks Danny :)
I just did a 2400 dpi scan and I can use it as desktop = 29 Mb image but this cool on my 30 inches screen. I will put this file on the inria web site for other lighhouse stamp lovers. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
david I would really like to continue the cleaning of SystemDictionary because I do not like the current state of affair. Now we can either have a namespace class (with only namespace behavior) both and a imageManagement class Now we could have one variable Smalltalk to point to either of it. them :) but we will need another name. Now the point behind the current (which I do not like but live with it is that) it would be cool to be able to do from my image some query into your image). This was about thinking about that that SmalltalkImage current got birth. Now I would love to get some discussions about a way to - have a class management class = SystemDictionary but with clean contents and cool name = namespace? (which often people confused with having namespace at the language level and it not part of the proposal don't open the box please) - have a cool abstraction over image housekeeping - a cool abstraction about vm information so if you have ideas please let me know. Stef On Jan 4, 2010, at 9:16 PM, David T. Lewis wrote: On Mon, Jan 04, 2010 at 07:09:01PM +0100, Laval Jannik wrote: Hi, I understand your comments, So: - i will put word size a class var, - this class var will be modify only by systemTracer Now I have a question: Why using Smalltalk wordSize whereas the vm parameter is getting by SmalltalkImage current ? Hi Jannik, Different people may answer this question in different ways, because it is a matter of style and personal opinion. But it may help to know that earlier versions of Squeak had the vm parameter query in SystemDictionary (Smalltalk) rather than in SmalltalkImage. This was moved as part of a larger effort to reorganize SystemDictionary, which is a rather large class that has accumulated many functions over the years. As matter of function, it makes no difference either way. The part that is subject to opinion is whether it makes more sense for a person to say Smalltalk wordSize to refer to the size of a word in the object memory, or whether SmalltalkImage current wordSize is more meaningful. FWIW, my own opinion is that neither one is right, but Smalltalk wordSize is easier to remember. But no matter what approach is taken, you will be able to find someone who does not agree, so you should form your own opinion ;-) HTH, Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Building Pharo and Plugins for Mac OS X and Linux
2010/1/4 David Li tawe...@yahoo.com: On Jan 5, 2010, at 3:24 AM, pharo-project-requ...@lists.gforge.inria.fr wrote: On Mon, Jan 4, 2010 at 7:19 PM, David Li tawe...@yahoo.com wrote: Hi, I am new to Pharo Hi and welcome! and wonder if there is a step by step instruction on building Pharo for Mac OS X and Linux. The only thing I am aware of is http://code.google.com/p/pharo/wiki/BuildingAVMOnPharo Thanks. I have come across that document as well. I kind of got stuck on figuring how how I can install VMMaker. Try (and proceed with the Warning) Gofer new squeaksource:'JBARepo'; package:'FFI-Kernel'; load. (Smalltalk at: #ExternalType) initialize. (Smalltalk at: #ExternalStructure) compileAllFields. Smalltalk recreateSpecialObjectsArray. Gofer new squeaksource:'VMMaker'; package:'VMMaker'; load. Hernán ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: Igor when I try to recompile TPureBehavioraddTraitSelector: I get a DNU ArraycreateMethod:header: because the system uses itself when I add a method to a trait. This morning I did something and it worked but now I do not remember and I'm thinking how to turn around the problem. Do you have an idea? you can restore the ArrayedCollectioncreateMethod:header: method, just temporary. So you will be able to produce methods using array of bytes as trailer. But it is strange.. i remember i fixed that method (addTraitSelector:) in pharo changesets. Or maybe it was something else. Stef methodAndNode := self compile: source classified: nil notifying: nil trailer: self defaultMethodTrailer ifFail: [^nil]. ?? yup. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Issues in 1.1 (was: Re: [update 1.1] #11126 - 27 (final ...))
yes this is probably easier. Glad I was looking for lenses :) I will do it now. Stef On Jan 4, 2010, at 9:57 PM, Igor Stasenko wrote: 2010/1/4 Stéphane Ducasse stephane.duca...@inria.fr: Igor when I try to recompile TPureBehavioraddTraitSelector: I get a DNU ArraycreateMethod:header: because the system uses itself when I add a method to a trait. This morning I did something and it worked but now I do not remember and I'm thinking how to turn around the problem. Do you have an idea? you can restore the ArrayedCollectioncreateMethod:header: method, just temporary. So you will be able to produce methods using array of bytes as trailer. But it is strange.. i remember i fixed that method (addTraitSelector:) in pharo changesets. Or maybe it was something else. Stef methodAndNode := self compile: source classified: nil notifying: nil trailer: self defaultMethodTrailer ifFail: [^nil]. ?? yup. -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Best regards, Igor Stasenko AKA sig. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Mac VM 5.2.b2 ships
John, thanks for the more precise directions (yesterday I gave up in confusion). To encourage other mac users to switch, here's the exact url: ftp://ftp.smalltalkconsulting.com/experimental/64bit/32bitImage*64bitVM/Squeak%2064-32%205.2b2.app.zip I've made this my default vm and so far so good (I can open and operate a bunch of my images). I'm looking forward to apple-Q, apple-H etc working. Thanks for the shiny new vm! -Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Thanks Danny :)
I put the stamp into https://gforge.inria.fr/frs/?group_id=1299 I will add the mp4 (apparently it did not make it). Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11135
11135 - fixing trailer: #(0 0 0 0) by adding first createMethod: numberOfBytesForAllButTrailer header: headerWord ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: 64 bit images (was Re: The Trunk: Collections-dtl.268.mcz)
On Mon, Jan 04, 2010 at 09:30:45PM +0100, St?phane Ducasse wrote: david I would really like to continue the cleaning of SystemDictionary because I do not like the current state of affair. Now we can either have a namespace class (with only namespace behavior) and a imageManagement class Now we could have one variable Smalltalk to point to either of it. but we will need another name. Now the point behind the current (which I do not like but live with it is that) it would be cool to be able to do from my image some query into your image). This was about thinking about that that SmalltalkImage current got birth. Now I would love to get some discussions about a way to - have a class management class = SystemDictionary but with clean contents and cool name = namespace? (which often people confused with having namespace at the language level and it not part of the proposal don't open the box please) - have a cool abstraction over image housekeeping - a cool abstraction about vm information so if you have ideas please let me know. Stef, I think it would be good to step away from the details and just think about the high level objects - what do they represent and what are they responsible for (http://www.wirfs-brock.com/Design.html)? Maybe there would be two or three classes involved, as few as possible. Then write the class comments for the empty classes. Think about it for a few weeks, and if it still makes sense then start the refactoring. But I would not touch a single line of code until the class comments are clearly written and understood. $0.02, Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Notifications of windows opening/closing/focus
Yes it would be good to see if this is ok to get it into the system. Stef On Jan 4, 2010, at 5:39 PM, Alexandre Bergel wrote: Gary, In this email I attached a .st file. Just load it, and it will install the change set to get notifications. A number of people already expressed their need for such an extension. Cheers, Alexandre MOMorphicExtensionInstaller.st On 4 Jan 2010, at 17:20, Gary Chambers wrote: Nothing like that currently or previously AFAIK. Regards, Gary - Original Message - From: Simon Denier simon.den...@inria.fr To: Pharo Development pharo-project@lists.gforge.inria.fr Sent: Monday, January 04, 2010 4:00 PM Subject: [Pharo-project] Notifications of windows opening/closing/focus Hi How do you get notified of windows opening, closing, or getting focus in Pharo? Is there some announcements or some older events? -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] [update 1.1] #11136
11136 - - Issue 1738:CompiledMethodTrailer post action So now this should be fixed. I should remove createHeader: I will do that during the next batches tomorrow evening. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about DependencyBrowser
Hi again Mariano, 2010/1/4 Mariano Martinez Peck marianop...@gmail.com: On Mon, Jan 4, 2010 at 8:34 PM, Hernán Morales Durand hernan.mora...@gmail.com wrote: Hi Mariano, Thank you for the feedback, I've updated the dependency browser package in SqueakSource, have a look for the latest package releases or evaluate the installation script again found in http://swikicaicyt.homeip.net/WebOpus/65 Cool, thank you very much for your work. Hey! I have more questions :) 3) Please, take a Pharo dev image and you will see that the package OCForOB for example, only depends on OmniBrowser and OB-Standard (using dependency browser). However, that package also depends on OCompletion I think. Look for example the method OBTextPanel createCompletionController (category ocforob) and you will see that it uses the class OController which is from the package OCompletionSo, shouldn't be OCompletion a dependency ? True, it is fixed now in the latest release. Yes, cool. At this in this case It is fixed :) 4) There are certain packages that are not listed in the dependency browser. Examples OB-Standard, OB-Morphic, O2-Standard , etc...most of them (maybe all) seem to have the pattern XXX-YYY. Do you know what can be the problem here? Maybe something related to what you told me about normalized and un-normalized? I would really like to see these packages also. No, this was a missing line in the package listing. Fixed too. This is not working very well. When you select OB , Refectoring or any other which is not normalized and it brings the popup, even selecting something the popup brings again and again and againand I THINK the amount of times the pop up raises is the amount of packages you have as dependencies (the size of the collection of the right ;) Maybe this can help you to detect the problem. Yes, I was aware of the problem, but I don't know if I want to fix it :) Seriously, the problem is a package name is not an object (well, it's a String...) so people can name packages as they want. (e.g. things like : MyPackage-MySubcategory1-MySubcategory2-MySubcategory3-... ) Besides that, or because of that, there are PackageInfo's for packages with names including arbitrary number of separators...please evaluate: ( PackageOrganizer default packages collect: [: pkg | pkg packageName ] ) asSortedCollection and scroll through Collections. There is a 'Collection' package and 11 more 'Collection-' packages. This kind of textual division of categories with separators is complicating things. My question is: Is the 'Collection' package one and there are 11 dirty package info's which should not be there, or there are 12 Collection packages and the one without subcategory name which is not shown in the Browser? Another problem I have right now is this example: NewInspector. It extends the class ProtoObject with this method: ProtoObject niChildrenBlockForFixedFields (an extension for NewInspector). In that method, it uses the class TypeCollector which is form RoelTyper. However, RoelTyper is not shon as a dependency. Do you know what can be the problem ? I have no idea but I will check it out, thanks for reporting. Cheers, Hernán ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] about DependencyBrowser
My question is: Is the 'Collection' package one and there are 11 dirty package info's which should not be there, or there are 12 Collection packages and the one without subcategory name which is not shown in the Browser? The are separate packages, have a look at PackageInfo#category:matches: Why don't you use PackageInfo to tell you what classes and methods are in a package, then you don't have to bother about category and protocol names? Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Notifications of windows opening/closing/focus
Indeed, that would be great. Doru On 4 Jan 2010, at 22:48, Stéphane Ducasse wrote: Yes it would be good to see if this is ok to get it into the system. Stef On Jan 4, 2010, at 5:39 PM, Alexandre Bergel wrote: Gary, In this email I attached a .st file. Just load it, and it will install the change set to get notifications. A number of people already expressed their need for such an extension. Cheers, Alexandre MOMorphicExtensionInstaller.st On 4 Jan 2010, at 17:20, Gary Chambers wrote: Nothing like that currently or previously AFAIK. Regards, Gary - Original Message - From: Simon Denier simon.den...@inria.fr To: Pharo Development pharo-project@lists.gforge.inria.fr Sent: Monday, January 04, 2010 4:00 PM Subject: [Pharo-project] Notifications of windows opening/closing/ focus Hi How do you get notified of windows opening, closing, or getting focus in Pharo? Is there some announcements or some older events? -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com When people care, great things can happen. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] Re: Mac VM 5.2.b2 ships
There is a bug in there some where. Some people report it work, it works here, but then sometimes it does not work. I'll devote some time to it later tonight. I'f you saw Stéphane comment: /Applications/Squeak/Squeak500b96432.app/Contents/MacOS/Squeak PharoCore-1.0-10503rc1.1.image test.st 2010-01-03 11:40:32.135 Squeak[46852:903] Can't open input server /Library/InputManagers/Inquisitor 2010-01-03 11:40:32.139 Squeak[46852:903] openFile state 1 with file PharoCore-1.0-10503rc1.1.image 2010-01-03 11:40:32.139 Squeak[46852:903] openFile state 0 with file test.st The 2010-01-03 11:40:32.139 Squeak[46852:903] openFile state 1 with file PharoCore-1.0-10503rc1.1.image 2010-01-03 11:40:32.139 Squeak[46852:903] openFile state 0 with file test.st are debug messages I have in the VM to print what is going on. The VM is given documents to open when it launches and later when you do things like drag and drop, or double-cllick an image. It has to open the first image it sees, it has to pass on other documents for processing by the startup logic or drag or drop. Or it has to decide the document is an image file and we've one open already so we need to launch another virtual machine process to open the image the guy want's open. On 2010-01-04, at 9:48 AM, Mariano Martinez Peck wrote: On Mon, Jan 4, 2010 at 3:33 PM, Simon Michael si...@joyful.com wrote: John, thanks for the more precise directions (yesterday I gave up in confusion). To encourage other mac users to switch, here's the exact url: ftp://ftp.smalltalkconsulting.com/experimental/64bit/32bitImage*64bitVM/Squeak%2064-32%205.2b2.app.zip I've made this my default vm and so far so good (I can open and operate a bunch of my images). But at the same time??? I cannot open more than one image at the same time with this version. When I try to open the second one, it is not open and even more, no matter what OS windows I have focus, it goes to the first image. It is like if it thinks that it has already opened the image. Cheers Mariano I'm looking forward to apple-Q, apple-H etc working. Thanks for the shiny new vm! -Simon -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Building Pharo and Plugins for Mac OS X and Linux
Ok, for the os-x the build instructions are here http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Mac%20OS/vm/Documentation/readme.txt?rev=1984view=auto If you want to build the os-x V5 beta version, then get the SVN tree from here http://svn.isqueak.org/vm/ and build the SqueakPureObjc.xcodeproj For linux http://squeakvm.org/unix/ That all precludes the install setup of VMMaker, but I always view that as the *easy* part. On 2010-01-04, at 10:19 AM, David Li wrote: Hi, I am new to Pharo and wonder if there is a step by step instruction on building Pharo for Mac OS X and Linux. I am working on a project that requires extension either through itself or via plugins. I have been seeing the mention of VMaker but can't find a good document about it. Thanks a lot for the help. David Li ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Building Pharo and Plugins for Mac OS X and Linux
On 2010-01-04, at 11:46 AM, David Li wrote: I am experimenting with Scratch and planning to integrate several native library into it. It seems that I can accomplish most of what I need via plugins. But it would be nice to get a clear pictures about how to build the VM and how the codes are structure in case I need to get in there. Personally I think the thing to do is expose the native library calls via FFI or Alien, then build the messy frame work for dealing with the library in smalltalk. Take a look at the GStreamer api I did in EToys for OLPC, or the Navigation services or quicktime stuff in Sophie. Or you can cheat a bit and also do most of the work in SLANG, see the Mac Menu Bar plugin as an example. Most code in SLANG with some cCode: for the api calls. === John M. McIntosh john...@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com === ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Notifications of windows opening/closing/focus
On 4 janv. 2010, at 17:39, Alexandre Bergel wrote: Gary, In this email I attached a .st file. Just load it, and it will install the change set to get notifications. I see. The fact that the actual changes are in a method makes it a bit hard to browse (I like to browse things before installing them) Only problem is how to subscribe to a new window announcer when it pops up by any means (world menu, button, do-it)? Should I scan World submorphs periodically? It does not seem right. Perhaps an announcement is missing in World, to notify a new window (then one can subscribe to the window) A number of people already expressed their need for such an extension. Cheers, Alexandre MOMorphicExtensionInstaller.st On 4 Jan 2010, at 17:20, Gary Chambers wrote: Nothing like that currently or previously AFAIK. Regards, Gary - Original Message - From: Simon Denier simon.den...@inria.fr To: Pharo Development pharo-project@lists.gforge.inria.fr Sent: Monday, January 04, 2010 4:00 PM Subject: [Pharo-project] Notifications of windows opening/closing/focus Hi How do you get notified of windows opening, closing, or getting focus in Pharo? Is there some announcements or some older events? -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] What about killing PharoWeb images?
Lukas Renggli reng...@... writes: If you are really into building images, you should build them for YOU and not for anybody else. Otherwise, I think, they are never going to fly. +1 --AA ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Beginner question :) search and replace in String
Levente Uzonyi le...@... writes: Why didn't it happen to smalltalk? I guess because the language tries to mimic natural languages. Btw I can't come up with a language that changed it's core library function names to shorter ones. The very same natural language argument can be used in favor of my point as well :) That is, if you *really* want to mimic the entire bandwidth of natural language, you should also mimic the tendency of natural languages to introduce abbreviations for common concepts. This is an *essential* part of any natural language. What should be said is that one should use whatever works best for himself. But a language that does not offer abbreviations to those that seek for them can IMHO not be called natural. The huffman coding presented in Akira's paper introduces shorter *aliases* for common methods. So you can pick and use what you want. So his paper is exactly about how they proceed when introducing short aliases in the evolution of the Ruby API. The full paper can be found here http://www.citeulike.org/article/6174874 Object #p is not really useful. Logging to Transcript is a bad practice anyway. Print-outs are not *per se* bad practice. They have their justification and should be part of anyones debugging tool set. So even if you dont agree with abbreviating print-out to #p, you should not ban them from you tool set! For example, nothing beats print-outs when you need to trace a feed of events. You would not want to put an #inspect inside a loop that is taken 10'000 times :) Speaking of loops, I changed #h to abbreviate #haltOnce rather than #halt. At least for my style of debugging, that proofed to be more useful. I won't comment on the rest, some prefer concise language, some like to keep it verbose. My point is that a language should offer short aliases for common terms, and I guess all of my examples are common enough to qualify for a shorter aliases based on that criterion--if you want to mimic the evolution of abbreviations in natural language. --AA ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] [squeak-dev] [ANN] SystemTracer on SqueakSource
On Mon, Jan 04, 2010 at 03:34:09PM +0100, Laval Jannik wrote: Hi David, I cannot load SystemTracing-dtl.11 in a pharoCore1.1. There is a syntax error in SystemTracingheadersFor:withHash:numFields: Is there another way to load the code ? Thanks, Jannik, Most likely this is the underscores in the method source. I ran FixUnderscores on package SystemTracing and saved it on SqueakSource as SystemTracing-dtl.12, so I think this should load now. Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Building Pharo and Plugins for Mac OS X and Linux
On Mon, Jan 04, 2010 at 09:04:26PM +0100, St?phane Ducasse wrote: David check the squeak documentation on how to invoke external library with FFI. In pharo you have also alien (not tested on non intel - works on mac). You do not have to recompile the vm to invoke external library. You define methods with specific pragmas annotations and the plugin code can be invoked. One if these days we should write a better doc http://wiki.squeak.org/squeak/2426 http://www.is.titech.ac.jp/~ohshima/squeak/DShowVideo/index.html http://www.visoracle.com/squeak/faq/ffi-windows.html http://wiki.squeak.org/squeak/356 VMMaker is published on SqueakSource. May be people with more experience will comment. Tim Rowledge's explanation of VMMaker is here: http://wiki.squeak.org/squeak/2105 You will also find detailed instructions for VM builders along with the platform source code, which is maintained in a Subversion source code repository at squeakvm.org: http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/ For example, documentation on building for Unix (Linux) will be found here: http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/unix/doc/HowToBuildFromSource.pdf And for Windows: http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/win32/docs/?rev=2147 which points to: http://squeakvm.org/win32/ And for Mac OS: http://squeakvm.org/cgi-bin/viewcvs.cgi/trunk/platforms/Mac%20OS/vm/Documentation/ as well as other documents that John mentioned in his reply. In other words, after you download the platform source code from the Subversion repository, you will find detailed documentation in the subdirectory for each of the major platforms. There is also a mailing list for the VM: http://lists.squeakfoundation.org/mailman/listinfo/vm-dev Dave ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] Gofer broken in PharoCore 1.0
Reported as http://code.google.com/p/pharo/issues/detail?id=1741 Gofer is broken on PharoCore 1.0. Can't run code like: Gofer it renggli: 'unsorted'; package: 'RFB'; load. and when updated with: Gofer gofer update. fails with an error. The fix is the same as http://code.google.com/p/pharo/issues/detail?id=1680 ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] Beginner question :) search and replace in String
On 05/01/2010 00:02, Adrian Kuhn wrote: I won't comment on the rest, some prefer concise language, some like to keep it verbose. My point is that a language should offer short aliases for common terms, and I guess all of my examples are common enough to qualify for a shorter aliases based on that criterion--if you want to mimic the evolution of abbreviations in natural language. Please bear in mind that natural languages have much more redundancy and less precision than programming languages. In addition, programming languages have handy tools like autocompletion that natural languages don't, making abbreviations less useful :) ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
