February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] moved repos to gemstone

by Nicolas Cellier

I just checked how hard it would be to merge wiresong FS into Pharo 1.4 And I noticed that a few references to Incomplete exception leaked out of Xtreams in the wiresong version and I think that it is a bug... (at least, from Pharo POV). We can all understand Lukas, any change of API will be a hurdle for applications and should be avoided as much as possible. Forking the implementation because the package authority cannot offer support for latest Pharo version is not a problem. But, from above POV, forking the API tests is THE BAD practice. That's why new features along with their test should be placed in proper FS-PharoExtensions, at least until eventually integrated in trunk by package authority. Forking the API is not a problem as long as resources meet ambitions. If not, maybe the efficiency of collaboration is worth a few compromises... Nicolas Le 15 fÃ©vrier 2012 18:52, Lukas Renggli <renggli(a)gmail.com> a Ã©crit : >>>> A quick comparison shows that the Pharo fork is based on outdated code and has some methods of the public API renamed. >>> >>> where's the other code located? I would like to check that. > > http://source.wiresong.ca/mc > >> Me too especially because I committed in FS on squeak source and not in Pharo so that colin can commit. Because originally I worked on PharoTaskForces. > > This is not how open-source works [1, 2]. Not even Pharo works like this. > >> In addition I do not see how we can control our life if we cannot publish on the repository of a part that should be central to us. > > I understand that you want to change things. Also I understand that > the original project might be too slow, or that the authors might not > accept your changes. In this case it is only fair to do a proper fork > [3], to choose a new name, and a new namespace. And to live with all > the consequences. > > Lukas > > [1] http://producingoss.com/en/getting-started.html#developer-guidelines > [2] http://subversion.apache.org/docs/community-guide/general.html > [3] http://producingoss.com/en/forks.html#forks-initiating > > -- > Lukas Renggli > www.lukas-renggli.ch >

Feb. 19, 2012

Re: [Pharo-project] moved repos to gemstone

by Nicolas Cellier

I had a quick look in squeaksource/fs and I just wonder... 1) why some API were renamed from the beginning (onDisk => disk inMemory => memory, basicOpen:writeable => etc...) Where was it discussed? What does it serve? Were a request emitted to FS maintainers? Shouldn't such discussion be public? 2) why do commit messages so rarely reflect the changes really going on inside? Do you think it's FS maintainers job to try understanding the purpose and necessity of your changes? 3) why do some garbage get published in the repository (like method #tt for example)? Do you expect maintainers merging garbage in the history, or just cutting such branches? 4) why haven't wiresong changes ever been merged into the squeaksource/fs fork? Do you consider FS maintainers work as null and void? Or do you expect them to commit their work in squeaksource/fs? Is there a development trunk? 5) shouldn't pharo extensions go into a specific package named FS-PharoExtensions? They can eventually be integrated by the FS maintainers, but I guess they have their own schedule. So that is the clean and well behaved way to dot it. IMO. I don't know were bad communication and bad practice come from, surely a bit from both sides... But I can say that I don't understand the development model at all... Who is responsible of what? What is expected from FS maintainers? What should or shouldn't Pharo developers do? I have the feeling there is no contract at all, just a great deal of autism... Nicolas Le 15 fÃ©vrier 2012 21:07, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> a Ã©crit : >> >> >>>>>> A quick comparison shows that the Pharo fork is based on outdated code and has some methods of the public API renamed. >>>>> >>>>> where's the other code located? I would like to check that. >>> >>> http://source.wiresong.ca/mc >>> >>>> Me too especially because I committed in FS on squeak source and not in Pharo so that colin can commit. Because originally I worked on PharoTaskForces. >>> >>> This is not how open-source works [1, 2]. Not even Pharo works like this. >>> >>>> In addition I do not see how we can control our life if we cannot publish on the repository of a part that should be central to us. >>> >>> I understand that you want to change things. Also I understand that >>> the original project might be too slow, or that the authors might not >>> accept your changes. In this case it is only fair to do a proper fork >>> [3], to choose a new name, and a new namespace. And to live with all >>> the consequences. >>> >>> Lukas >>> >>> [1] http://producingoss.com/en/getting-started.html#developer-guidelines >>> [2] http://subversion.apache.org/docs/community-guide/general.html >>> [3] http://producingoss.com/en/forks.html#forks-initiating >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >> >> Cooperation has to be mutual. > > This is what I thought too but I'm naive. > >> I don't know enough about the history of all this, but I completely fail to understand how someone who wrote something like FileSystem > > I started to really want to use FS so I started to comment it and publish my change in PharoTaskForces and people told me that > I should share so did I and I put a FS project on Squeaksource and colin pubslihed one version there. Â thought that he would continue to > publish there but not. This is ok. Now let us be free. I do not think that it makes sense to continue like that. > >> or RB would not find it interesting that his code would be included by default in Pharo (and thus support a mutual cooperation). > > Because we want to change some of the approach to be able to manage remote refactorings and this goes against the Design of RB but > with Â bit of discussions and positive energy if would be probably easy to get somewhere. Now we will see and probably have to fork. When people do not want to collaborate then you work on your own. > > We arrived to the point that for example for SmallLint we will have to fork everything because we do not dare to propose extensions. > And to collaborate you should trust people and there is not even an inbox in SmallLint and other projects. So this measn that changes are not welcomed. > This is ok too but this is another approach. > > Simple. This is just sad to see a microscopic world with nearly no impact on industry struggling instead of pushing in the same direction. > Anyway we will do it. Because Pharo deserves better vision than that. > >> Being in an image by default means much more usage and true OSS feedback, it will only improve things. >> >> We have to work together to make progress. > > Not necessarily ... > > Stef >> >> Anyway, that is my opinion. > >

Feb. 19, 2012

[Pharo-project] Crash dump Cog Linux for Debugger opening up

by S Krish

Will dig in further.. but if anyone has seen this and already fixed for 1.4 ..

Feb. 19, 2012

Re: [Pharo-project] debugger menu items inconsistent with buttons ( & "Begin Debugging Again" enhancement )

by S Krish

Provided you cannot unit test the startup script by a tear down reset of all the is done in startup, you need to bother about these details.. else rerun should help in a Test Runner context.Can the startup script be broken up and tested in units..? On Fri, Feb 17, 2012 at 8:41 PM, Ben Coman <btc(a)openinworld.com> wrote: > > I notice that the function of debugger menu items > Step, Step through & Send > seem to correspond respectively to debugger buttons > Over, Through & Into > but the text doesn't really align. > > Perhaps better menu items would be: Step Over, Step through block, Step > Into. > > On another topic, once you have stepped past the point where the debugger > opened, is there any way the debugger might be returned to the context > where it initially opened? > For instance, if you are debugging your startup script by putting a halt > in the script, then then if you accidentally step past where the debugger > opened, you can no longer use the <Restart> button and have to quit and > restart Pharo to get back to the same debugging point. A menu item to > "Begin Debugging Again At The Same Initial Point" would be nice but perhaps > this is not feasible, or I've missed something > > cheers, -ben > > > >

Feb. 19, 2012

Re: [Pharo-project] Marking methods

by S Krish

Should not be difficult to mark with self flag: 'xyz' Run through the Packages ( if you are sure ) alone to later revert/ remove them.. or the whole system if so required, does not really that much time to find all sender methods of flag:. Probably give a browser customized to then selectively remove, edit or do anything needed. On Tue, Oct 25, 2011 at 2:48 PM, Bernat Romagosa < tibabenfortlapalanca(a)gmail.com> wrote: > Hi list, > > I've been thinking for a while that it'd be great if we could somehow > graphically mark methods in the browser. Like adding an icon next to their > name or highlighting them in different colors. > > When reviewing code, I find myself going through methods and would love to > be able to mark them once they've been reviewed, to prevent me from going > through them again. > > Does anyone else have the same needs? How do you guys manage this? I > thought about flagging methods, but that'd mean I'd have to read through > all my methods again to remove the flags once I'm done with the revision. > > Cheers, > -- > Bernat Romagosa. >

Feb. 19, 2012

Re: [Pharo-project] Fwd: [Moose-dev] configuring moose

by Philippe Marschall

On 19.02.2012 12:18, StÃ©phane Ducasse wrote: > Moose :) Nile-Base is repeated 5 times. If you exclude duplications you go from 419 to 162. Cheers Philippe

Feb. 19, 2012

Re: [Pharo-project] Putting source code in method trailer [WAS] Re: Speeding up Finder string search

by Mariano Martinez Peck

On Sun, Feb 19, 2012 at 2:37 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 19 February 2012 00:54, Craig Latta <craig(a)netjam.org> wrote: > > > > Hi-- > > > > If you have some way of uniquely identifying a method, then you can > > put the source wherever you like (e.g., in some other live object > > memory), and look it up when you need it. For an example, see the > > MethodID class in Spoon[1]. > > > indeed. > it is really unimportant where to store the method(s). > They can be stored in file, remote DB or remote image.. > But first we need to change the system to work in that way, by > removing hardcoded > SourceFiles everywhere and replacing with nice polymorphic source > manager(s). > > +1 to both. having an abstact SourceManager with a LocalFileBaseSourceManager and Pharo defualt using that would be awesome. Imagine we can then plug different ones. This is a really interesting idea/project in case someone wants to investigate.... > > > > -C > > > > [1] http://dl.dropbox.com/u/15188004/spoon/Spoon%203%20alpha%203.zip > > > > -- > > Craig Latta > > www.netjam.org/resume > > +31 6 2757 7177 > > + 1 415 287 3547 > > > > > > > > > > -- > Best regards, > Igor Stasenko. > > -- Mariano http://marianopeck.wordpress.com

Feb. 19, 2012

Re: [Pharo-project] changing a method on an image file without loading the image

by Igor Stasenko

what we did with Camillo last time is putting ^self bytecode into offending method. It is easy to do: - open an image which is close to one which is broken, find the offending method, then check its bytecode. now open the broken image in binary/hex editor and search for bytecode sequence. To make sure that you editing right place, you should choose the unique bytecode sequence, so if offending method is not-so unique, like '^ self foo' then look in method foo etc. Then you just change the first bytecode of that method to return nil or self (whatever fits) and like that image can boot and you will be able to fix it. -- Best regards, Igor Stasenko.

Feb. 19, 2012

Re: [Pharo-project] Putting source code in method trailer [WAS] Re: Speeding up Finder string search

by Igor Stasenko

On 19 February 2012 00:54, Craig Latta <craig(a)netjam.org> wrote: > > Hi-- > > Â Â If you have some way of uniquely identifying a method, then you can > put the source wherever you like (e.g., in some other live object > memory), and look it up when you need it. For an example, see the > MethodID class in Spoon[1]. > indeed. it is really unimportant where to store the method(s). They can be stored in file, remote DB or remote image.. But first we need to change the system to work in that way, by removing hardcoded SourceFiles everywhere and replacing with nice polymorphic source manager(s). > > -C > > [1] http://dl.dropbox.com/u/15188004/spoon/Spoon%203%20alpha%203.zip > > -- > Craig Latta > www.netjam.org/resume > +31 6 2757 7177 > + 1 415 287 3547 > > > -- Best regards, Igor Stasenko.

Feb. 19, 2012

Re: [Pharo-project] Need help with OpenGL visual creation on linux

by Igor Stasenko

btw, to rebind to right version of glXGetProcAddress(), try glXGetProcAddress("glXGetProcAddress") :) i do something similar to this for windows. On 19 February 2012 14:57, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 18 February 2012 04:15, Javier PimÃ¡s <elpochodelagente(a)gmail.com> wrote: >> After one day of very low level debugging I found part of the problem. I'll >> explain because maybe I'm doing something wrong. >> >> There seem to be a duplicated load of the opengl library, one for statically >> linked calls and other dynamically loaded. >> >> I tried in gdb >> >> $> p listVisuals() >> which calls directly to XGetVisualInfo and worked (found ~84 visuals). >> >> then I tried something more interesting, by manually calling >> display_ioGLcreateContext from gdb, which calls glXChooseVisual. And it >> worked again. >> >> After much debugging, I found that loading glXGetProcAddress dynamically >> with dlsym from /usr/lib/libGL.so gave an address different to the one gdb >> gives if directly doing >> >> $> p glXGetProcAddress("glXChooseVisual") >> >> so there are 2 glXGetProcAddress. This is because one is loaded with dlsym >> (1) and the other is loaded automatically because the vm is linked against >> libGL (2). Calling (1) to get addresses of gl functions gives different >> addresses for all functions than calling (2). >> >> Calling glXChooseVisual with the address fetched by (1) fails, but if using >> (2) it works. This is really strange to me.Â The way to fix it is to get >> glXGetProcAddress from NativeBoost VMModule instead of '/usr/lib/libGL.so'. >> >> Now with this I have the opengl example almost working in linux (I hope). >> > I hoped that it is not so at least on Linux. > > But now , you see yourself, why i had to customize a "make call" and > function lookup logic > in OpenGL API. Exactly because of that. > One should use glXGetProcAddress for fetching the function pointers, > but in addition to that, > depending on context which is currently active, a different > function(s) can be available (or not). > So, it is late bound (similar to per-class dictionary in smalltalk). > This is why every instance of NBOpenGLAPI holds a list of function > pointers and fills them dynamically. > >> On Sun, Feb 12, 2012 at 4:23 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> ok, so >>> >>> If no conforming visual exists, NULL is returned. >>> It is hard to imagine, that these attributes not supported >>> >>> Â {GLX_RGBA. GLX_DEPTH_SIZE. >>> Â 24. >>> GLX_DOUBLEBUFFER. 0} >>> >>> the code seems to be fine. >>> >>> This is what i found: >>> >>> ------- >>> http://www.opengl.org/wiki/Programming_OpenGL_in_Linux:_GLX_and_Xlib >>> >>> If glXChooseVisual returns with success, the visual's id will be >>> output. If NULL is returned, there is no visual that fulfills your >>> needs. In that case, check the output of glxinfo again. Maybe you have >>> to use a different depth buffer size (GLX_DEPTH_SIZE, 16 instead of >>> GLX_DEPTH_SIZE, 24), or you could even have to remove the >>> GLX_DEPTH_SIZE (or the GLX_DOUBLEBUFFER) entry. This should be >>> considered especially if you want to create programs not only for your >>> computer, but for other ones: You should code your program in a way >>> that it can check a list of different combinations of visual >>> attributes, because the capabilities depend heavily on the hardware. >>> ----- >>> They also using >>> vi = glXChooseVisual(dpy, 0, att); >>> >>> second argument = 0. not #defaultScreen. >>> >> >> yes, I tried all this. first with 0, then with defaultScreen, which returns >> 0. >> >>> >>> On 10 February 2012 19:59, Javier PimÃ¡s <elpochodelagente(a)gmail.com> >>> wrote: >>> > yes, notice that it is in a different >>> > repo:Â http://www.squeaksource.com/NBXLib >>> > >>> > >>> > On Fri, Feb 10, 2012 at 3:53 PM, Igor Stasenko <siguctua(a)gmail.com> >>> > wrote: >>> >> >>> >> On 10 February 2012 19:48, Javier PimÃ¡s <elpochodelagente(a)gmail.com> >>> >> wrote: >>> >> > To load NBOpenGL-X package you need to load NBXLib-core first >>> >> > >>> >> i don't see it. did you uploaded it? >>> >> >>> >> > >>> >> > On Fri, Feb 10, 2012 at 3:39 PM, Igor Stasenko <siguctua(a)gmail.com> >>> >> > wrote: >>> >> >> >>> >> >> Btw, javier i cannot load your package to check what you did: >>> >> >> >>> >> >> This package depends on the following classes: >>> >> >> Â NBXLibConstants >>> >> >> You must resolve these dependencies before you will be able to load >>> >> >> these definitions: >>> >> >> Â NBGLXContextDriver >>> >> >> Â supportsCurrentPlatform >>> >> >> Â createContext: >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> On 10 February 2012 19:34, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >> >> > On 10 February 2012 19:19, Lawson English <lenglish5(a)cox.net> >>> >> >> > wrote: >>> >> >> >> Is that code even ready for consumption? >>> >> >> >> >>> >> >> >> I was told that until there is a new ConfigurationOfNBOpenGL >>> >> >> >> ready, >>> >> >> >> to >>> >> >> >> not >>> >> >> >> load the new packages. >>> >> >> >> >>> >> >> > >>> >> >> > you could try :) >>> >> >> > >>> >> >> > but this is what i working on now (slowly integrating the parts of >>> >> >> > Javier's code, >>> >> >> > because not everything which he did i like ;) >>> >> >> > >>> >> >> > >>> >> >> >> L. >>> >> >> >> >>> >> >> >> >>> >> >> >> On 2/10/12 10:12 AM, Javier PimÃ¡s wrote: >>> >> >> >> >>> >> >> >> I'm trying to create an OpenGL context on linux but >>> >> >> >> glxChooseVisual >>> >> >> >> fails. >>> >> >> >> Maybe there's someone there experienced with this that can help. >>> >> >> >> >>> >> >> >> The code I'm trying is: >>> >> >> >> >>> >> >> >> display := NBXLibDisplay open. >>> >> >> >> window := display defaultRootWindow. >>> >> >> >> visualInfo := NBXLibVisualInfo fromPointer: (gl chooseVisual: >>> >> >> >> display >>> >> >> >> screen: display defaultScreen attributes: {GLX_RGBA. >>> >> >> >> GLX_DEPTH_SIZE. >>> >> >> >> 24. >>> >> >> >> GLX_DOUBLEBUFFER. 0} asWordArray). >>> >> >> >> ... >>> >> >> >> >>> >> >> >> but chooseVisual returns a null pointer. I even tried putting an >>> >> >> >> array >>> >> >> >> with >>> >> >> >> only 0 on attributes but didn't work either (and these attributes >>> >> >> >> should be >>> >> >> >> supported). >>> >> >> >> >>> >> >> >> Any idea of what could be wrong? The code is available to test in >>> >> >> >> squeaksource, you need nativeboost+NBXLib to try >>> >> >> >> >>> >> >> >> Cheers, >>> >> >> >> Javier >>> >> >> >> >>> >> >> >> -- >>> >> >> >> Lic. Javier PimÃ¡s >>> >> >> >> Ciudad de Buenos Aires >>> >> >> >> >>> >> >> >> >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > -- >>> >> >> > Best regards, >>> >> >> > Igor Stasenko. >>> >> >> >>> >> >> >>> >> >> >>> >> >> -- >>> >> >> Best regards, >>> >> >> Igor Stasenko. >>> >> >> >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Lic. Javier PimÃ¡s >>> >> > Ciudad de Buenos Aires >>> >> >>> >> >>> >> >>> >> -- >>> >> Best regards, >>> >> Igor Stasenko. >>> >> >>> > >>> > >>> > >>> > -- >>> > Lic. Javier PimÃ¡s >>> > Ciudad de Buenos Aires >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Lic. Javier PimÃ¡s >> Ciudad de Buenos Aires > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Feb. 19, 2012