May 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Excluding an autogenerated methods from MC package. How?

by Igor Stasenko

Hello all, say, i have some methods having automatically generated sources, and i want them to be not included into a package, since they are generated/refreshed anyways once package loaded. Is there a way to tell MC 1. to exclude such methods, when writing a package 2. to ignore any changes to these methods and don't mark a package as dirty ? -- Best regards, Igor Stasenko AKA sig.

May 21, 2010

[Pharo-project] Trying to understand raised....

by StÃ©phane Ducasse

Hi I'm trying to follow the event raised when adding a new class/package.... and this is a bit obscure. If I remember there is a tool to get a better understanding of the events raised by the system. Does anybody as a pointer? Stef

May 21, 2010

[Pharo-project] Symbol>>isBinary

by stephane ducasse

binary messages are not frequently called infix ones in our parlance so isBinary seems better. Symbol>>isBinary "Answer whether the receiver is a binary message selector." ^ self precedence == 2 Stef

May 21, 2010

Re: [Pharo-project] inbox cleaning

by Mariano Martinez Peck

I think all this have sense in the automate it. So, I would use Gofer (if possible) to script such things. If you have that, then call it from Hudson should be easy. But please, please, please, if we change this, we need to change all the documents and website where we explain the submit code steps. For example, there we say that if you only touch one package, no need of a slice. And even the name of the slice may change (as I read here). Cheers Mariano On Thu, May 20, 2010 at 4:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Me tooooooooooo > > > > I sort of prefer: > > SLICE-IssueXYZM-DescriptionOfIssue (possibly without the Issue prefix) > > That way all slices are next to each other in the inbox, and ordered by > number, which makes it much easier to find what you're looking for, either > when starting out with an issue from the bug tracker you need to integrate, > or when you're looking at which slices are in inb > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 21, 2010

Re: [Pharo-project] Remove developing with Pharo

by Mariano Martinez Peck

I have just read it and it is very cool :) Thanks Andrei, we really appreciate it. After several experiments from you and the rest, we can add a little sections of how to "tune it" and get the better performance as possible. Taking into account the tips people said in this thread, like Levente. I would like to experiment, but I don't have a remote machine hahaha. Thanks again. Mariano 2010/5/20 Andrei Stebakov <lispercat(a)gmail.com> > I created a chapter called "Remote Development" under the "Tips and Tricks" > chapter. > Here is the link: > http://book.pharo-project.org/book/TipsAndTricks/RemoteDevelopment/?_s=q1YO… > > > 2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com> > > Andrei: Once you have finished to make it work and how to tune it to make >> it faster, it would be great if you can write this in a section/chaper of >> the collaborative pharo book: http://book.pharo-project.org/ >> >> If you want I can creat you a user, and the section...then you only need >> to write ;) >> >> >> cheers >> >> mariano >> >> 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com> >> >>> Ok, I figured it out. >>> On the remote machine just start pharo with RFBServer started (connection >>> passwords must be set!) >>> On the local Windows machine open ssh or putty tunneling local port 5900 >>> to the remote port 5900 (putty -L 5900:localhost:5900 username(a)doman.com >>> ). >>> After that start a VNC client (in my case I installed TightVNC) and >>> connect to your local machine. >>> That will automatically establish a tunneled traffic between those two >>> systems va ssh tunneling. >>> >>> >>> 2010/5/14 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>> I paste a text I got from an old mail: "The latest version on >>>> squeaksource works. You can load it from http://squeaksource.com/RFB(Note that this package has been forked at least three times.) We used to >>>> connect to the server with RealVNC with the following settings: ZRLE >>>> encoding (disable auto select), Full color. IIRC you should also turn >>>> off the "render cursor locally" feature. >>>> On the server you should allow ZRLE and turn off the conserve memory >>>> feature. >>>> " >>>> >>>> In addition, ask in seaside mailing list too. You will probably receive >>>> more help. >>>> >>>> Cheers >>>> >>>> Mariano >>>> >>>> >>>> >>>> 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com> >>>> >>>>> Exactly what VNC slient I can use on Windows? >>>>> I tried VNC viewer free ( >>>>> http://www.realvnc.com/products/free/4.1/winvncviewer.html) trying to >>>>> connect to the locally run Pharo and the viewer fails with "uncknown rect >>>>> encoding" after which Pharo image also freezes. >>>>> Is there any step-by-step tutorial how to setup VNC (remote Linux, >>>>> local Windows)? >>>>> >>>>> >>>>> On Thu, May 13, 2010 at 6:26 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >>>>> >>>>>> 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com>: >>>>>> > Interesting! Is it done on the X-server side or client? >>>>>> > >>>>>> you should have settings in your VNC client. >>>>>> also, you could set bpp for image. >>>>>> both could help to run things faster. >>>>>> >>>>>> > On Thu, May 13, 2010 at 5:38 PM, Igor Stasenko <siguctua(a)gmail.com> >>>>>> wrote: >>>>>> >> >>>>>> >> 2010/5/12 Andrei Stebakov <lispercat(a)gmail.com>: >>>>>> >> > That's right, looks like it sends full-blown images (not the >>>>>> delta, not >>>>>> >> > the >>>>>> >> > commands to x-server) and re-drawing takes forever. I wonder if >>>>>> it's a >>>>>> >> > Pharo >>>>>> >> > issue or x-server's? My xterm works pretty fast compared to Pharo >>>>>> >> > though... >>>>>> >> > >>>>>> >> lowering the pixel depth to 8bpp helps :) >>>>>> >> >>>>>> >> > 2010/5/12 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >>>>>> >> >> >>>>>> >> >> I have at times done what you are attempting, and painful is >>>>>> nicest >>>>>> >> >> adjective I can think to use. Please let us know if VNC is a >>>>>> better >>>>>> >> >> option. Re RDP, I have wondered whether the poor performance >>>>>> could be >>>>>> >> >> telling us something about the amount of drawing that might be >>>>>> >> >> happening for >>>>>> >> >> no purpose??? It can be terribly slow, especially the response >>>>>> to >>>>>> >> >> typing. >>>>>> >> >> Bill >>>>>> >> >> >>>>>> >> >> ________________________________ >>>>>> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>>>> >> >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf >>>>>> Of >>>>>> >> >> Mariano >>>>>> >> >> Martinez Peck >>>>>> >> >> Sent: Wednesday, May 12, 2010 10:25 AM >>>>>> >> >> To: Pharo-project(a)lists.gforge.inria.fr >>>>>> >> >> Subject: Re: [Pharo-project] Remove developing with Pharo >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> 2010/5/12 Andrei Stebakov <lispercat(a)gmail.com> >>>>>> >> >>> >>>>>> >> >>> Currently I have my web applications running on a Ubuntu box to >>>>>> which >>>>>> >> >>> I >>>>>> >> >>> connect from a remote WinXP system via ssh. >>>>>> >> >> >>>>>> >> >> I guess the subject should be "remote" instead of "remove" ? >>>>>> ;) >>>>>> >> >> >>>>>> >> >> Sorry I ask but why not you cannot just develop in your pc and >>>>>> with scp >>>>>> >> >> or >>>>>> >> >> similar you copy the .image and .image file trough ssh to the >>>>>> server ? >>>>>> >> >> >>>>>> >> >>> >>>>>> >> >>> My current set of tools is Lisp/Slime/Emacs. >>>>>> >> >>> I tried to launch Pharo with X11 forwarding using X-server on >>>>>> WinXP, >>>>>> >> >>> but >>>>>> >> >>> it painfully slow (the Pharo main windows redraws in a few >>>>>> minutes). >>>>>> >> >>> I am really thinking developing some web app using >>>>>> Pharo/Seaside (I am >>>>>> >> >>> liking the language more and more!) but I need to know to do it >>>>>> >> >>> remotely via >>>>>> >> >>> a secure connection. >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> Yes, there is an implementation of the VNC protocolol. You can >>>>>> take a >>>>>> >> >> Pharo image and load a VNC server. Then, you can connect to any >>>>>> VNC >>>>>> >> >> client >>>>>> >> >> and what you see is the image....Then you can do whatever you >>>>>> want. I >>>>>> >> >> don't >>>>>> >> >> know the performance, thus. >>>>>> >> >> >>>>>> >> >> That package is called RFB (remote something buffer) >>>>>> >> >> >>>>>> >> >> http://book.seaside.st/book/advanced/deployment/maintaining/vnc >>>>>> >> >> >>>>>> >> >> To install it: >>>>>> >> >> >>>>>> >> >> Gofer it >>>>>> >> >> squeaksource: 'MetacelloRepository'; >>>>>> >> >> package: 'ConfigurationOfRFB'; >>>>>> >> >> load. >>>>>> >> >> ((Smalltalk at: #ConfigurationOfRFB) project perform: >>>>>> #latestVersion) >>>>>> >> >> load. >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> Cheers >>>>>> >> >> >>>>>> >> >> Mariano >>>>>> >> >> >>>>>> >> >> >>>>>> >> >>> >>>>>> >> >>> Thank you, >>>>>> >> >>> Andrei >>>>>> >> >>> >>>>>> >> >>> _______________________________________________ >>>>>> >> >>> Pharo-project mailing list >>>>>> >> >>> Pharo-project(a)lists.gforge.inria.fr >>>>>> >> >>> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >> >> >>>>>> >> >> >>>>>> >> >> _______________________________________________ >>>>>> >> >> Pharo-project mailing list >>>>>> >> >> Pharo-project(a)lists.gforge.inria.fr >>>>>> >> >> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >> > >>>>>> >> > >>>>>> >> > _______________________________________________ >>>>>> >> > Pharo-project mailing list >>>>>> >> > Pharo-project(a)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(a)lists.gforge.inria.fr >>>>>> >> >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> > >>>>>> > _______________________________________________ >>>>>> > Pharo-project mailing list >>>>>> > Pharo-project(a)lists.gforge.inria.fr >>>>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> > >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Igor Stasenko AKA sig. >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 21, 2010

Re: [Pharo-project] [squeak-dev] Need your opinion: What is most appealing form for GL function bindings?

by Igor Stasenko

Hello , all i made a decision I'd like to thank you for your help. Please, forgive me, if its not your favorite choice. It is hard to make everyone happy. So, here the winner: readPixels_x: "in" x y: "in" y width: "in" width height: "in" height format: "in" format type: "in" type pixels: "out" pixels "This method was automatically generated from OpenGL specs" "See http://squeaksource.com/OpenGLSpecs for details" <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self glApiCall: #( void glReadPixels ( GLint x , GLint y , GLsizei width , GLsizei height , GLenum format , GLenum type , GLvoid* pixels ) ) index: 1334 attributes: #( #category #'VERSION_1_0' #version #'1.0' ) For 1-arg: arrayElement: "in" i "This method was automatically generated from OpenGL specs" "See http://squeaksource.com/OpenGLSpecs for details" <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self glApiCall: #( void glArrayElement ( long i ) ) index: 15 attributes: #( #category #'VERSION_1_1_DEPRECATED' #deprecated #'3.1' #version #'1.1' ) -- Best regards, Igor Stasenko AKA sig.

May 21, 2010

[Pharo-project] What packages to load from Metacello in PharoDev?

by Mariano Martinez Peck

Hi. For building PharoDev images, we take a PharoCore and just evaluate something like: (ConfigurationOfPharo project version: '1.1-beta1.10517') load So....Metacello would be boostraped from ConfigurationOfPharo>>ensureMetacello which does a (Smalltalk at: #ConfigurationOfMetacello) perform: #loadLatestVersion and ConfigurationOfMetacello>>loadLatestVersion does a "self project latestVersion load" ... and, the default of ConfigurationOfMetacello is Core....so, in summary, only core is loaded. Perfect. Now I was thinking that we should load more packages in PharoDev image. First, we want the Metacello tests. For all packages we include by default in PharoDev, we also include its tests (by default). This is cool because people test it, we can give you quick feedback, be sure all green tests, etc. They are cool as documentation, blah blah blah. So, first question, which tests package should I load? Metacello-Tests Metacello-TestsCore Metacello-TestsMC Metacello-TestsPlatform.pharo Metacello-TestsReference Or, maybe even better, load the group 'Test'. I guess this is the correct one. Now, I also think we could include all the following packages: - Tutorial: this is cool for newcomers. They want to do the Metacello tutorial, and having it already in the image is cool I think. I want to include also the tests for the tutorial - HelpSystem for Metacello: we need to copy this package from the HelpSystem repo (see my other email) - Metacello ProfStef - Metacello OB: do you know if it is working in Pharo 1.1 and with OB 1.1.4 ? What do you think about including these packages in PharoDev by default ? I think it is a good idea. Regardless that, I am not sure how to load them. As I told you, when building PharoDev images, Metacello is boostraped from the #ensureMetacello of ConfigurationOfPharo. And this will load the Core. ANd this is correct because other people use COnfigurationOfPharo for their own stuff and they just want the core. But in the case of PharoDev, I want more packages. But modifying #ensureMetacello is not an alternative. So...I can put a reference to ConfigurationOfMetacello in Conf of Pharo, just like any other dependency, and there I specify the loads: with the array of things I want. This seems better. But I still have a problem: #ensureMetacello will load the latestVersion of it. It will load core. So, which version of ConfigurationOfMetacello should I use in my version of ConfigurationOfPharo. If I put a specific version, I may hve problems because it will try to download different versions....So, I would like to load the same as the #ensureMetacello. But I cannot specify in version method lastVersion for metacello. what can I do ? don't specify the metacello version in the version method so that it takes the last one ? Thanks and sorry for the long email Mariano

May 21, 2010

Re: [Pharo-project] [squeak-dev] Need your opinion: What is most appealing form for GL function bindings?

by Lukas Renggli

7. gl glVertex3f(x, y, z) http://scg.unibe.ch/research/helvetia/examples#155976728 Ok, that requires quite some support code and doesn't work in the latest Pharo yet, but is also something to consider :-) Lukas On 20 May 2010 17:47, Igor Stasenko <siguctua(a)gmail.com> wrote: > There are multiple GL bindings exists by now > - one that used by Croquet (FFI) > - another one that using Alien > > and i doing one more, which using NativeBoost for callouts. > > And the question, what form of selectors you like most, > pros/cons .. i need to know, because i can pick any of them, > but i hope, that i will not be only one who using this stuff, so i > need your opinion. > > Lets take a usual OpenGL function: > > void glVertex3f(GLfloat x, GLfloat y, GLfloat z) > > A Croquet/FFI bindings translates it to a following selector: > > 1. glVertex3f: x with: y with: z > > An Alien bindings using following form: > > 2. glVertex3fX: x y: y z: z > > Since my bindings will definitely use underscores, its not a problem > to use a following one: > > 3. glVertex3f_x: x y: y z: z > > Currently i using this one: > > 4. glVertex3f: x y: y z: z > > In private mail with Andreas, he proposed a following: > --- > The one thing I'd consider is to use #comma: as the 'standard' keyword > instead of #with: for example: > > 5. glVertex3f: x comma: y comma: z > > The reason should be obvious; you're replacing the comma so it should > be a little more clear than using #with:. > --- > > 6. this option actually not about positional arguments, but about > omitting the 'gl' prefix for each function name. > It is because, you already typing gl at each invocation: > > gl glVertex3f: x with: y with: z > > so, maybe it worth to omit gl prefix, so, a code will look like: > > gl Vertex3f: x with: y with: z > > (sure thing, one may use different name for api interface object, not > 'gl'.. but i think that in 99.9% > cases, 'gl' is a natural choice). > > --- > > My own choice is [3]. > As to me, it helps greatly when you coding, > so, once you autocomplete the selector, you know what parameter you > need at each position, > unlike anonymous keywords, like with: or comma: , which don't telling > you anything about arguments you end up browsing docs each time. > Oh, and btw, each time you need to change something, you again may > need to refer to docs, > since it still may be not clear, what argument types a function > expects even if you look at already working code. > > The pro for picking [1] is mainly be compatible with lots of Croquet > code which using GL. > Except that, in NB bindings, i taking a constant names as is , i.e. > GL_LINES, while croquet > uses GLLines. So, its still will require porting. > > > P.S. i'm already having some stuff working (see attachment).. But i > little bit hesistant to do more, because then , if i reconsider > about selector names, it will require a lot of fixes all around places. > It generating all these methods automatically, so i can change a form > at any moment. > NBOpenGL methodDict size 2063 > NBWgl methodDict size Â 132 > NBGlx methodDict size 121 > > -- > Best regards, > Igor Stasenko AKA sig. > > > > -- Lukas Renggli www.lukas-renggli.ch

May 21, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by Igor Stasenko

Thanks, Mariano. Now i can test my stuff on it.. On 21 May 2010 11:35, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > 2010/5/21 Mariano Martinez Peck <marianopeck(a)gmail.com>: >> >> >> On Fri, May 21, 2010 at 6:35 AM, Serge Stinckwich >> <serge.stinckwich(a)gmail.com> wrote: >>> >>> There is no warning when you try to access a monticello repository >>> with a password and you enter the wrong password. >>> The repository just look empty. >>> >> >> This this is wrong from my point of view. >> >> Anyway, wasn't it like that also in 1.0 ?Â can you check ? >> > > Yes same behavior with 1.0 > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 21, 2010

Re: [Pharo-project] Where should I put ConfigurationOfGLMorphic

by StÃ©phane Ducasse

The process we envision is the following one. - add it to your project - then we will create Pharo10MetacelloRepository Pharo11MetacelloRepository and you will publish it there too. On May 21, 2010, at 5:01 AM, Javier PimÃ¡s wrote: > Hi, I made a very basic ConfigurationOfGLMorphic that manages it's dependency on FFI. Where should I upload this configuration now? > > Regards, > Javier. > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 21, 2010