June 2013 - Pharo-dev - lists.pharo.org

Possible PharoVM bug (wrong object on stack top)

by Max Leske

Hi I've been seeing a particular bug that I can only see when using the PharoVM and I was wondering if anybody else has been having the same issue. Under certain condition, a debugger will open displaying "SmallInteger does not understand <some message>". The stack top contains an integer (something of the form 138402, not sure how many digits), which explains the message. However, the situation actually looks like this: htmil anchor id: 'foo'; â¦ In this example, the error would be "SmallInteger does not understand #id:". So the stack top contains an integer instead of the receiver. Restarting the execution of the method and proceeding fixes the problem. I think I've seen that (using seaside), a new session will trigger the bug again. Apart from Seaside, I've also seen the same problem when loading Roberto Minelli's DevFlow into a Pharo 2.0 image. The debugger will open on a Metacello method. VM: latest PharoVM image: latest 2.0 try this config: http://smalltalkhub.com/#!/~RobertoMinelli/DevFlow with "ConfigurationOfDevFlow loadDevelopment" Has anybody else encountered this? Cheers, Max

June 27, 2013

Re: [Pharo-dev] question about HandMorph

by StÃ©phane Ducasse

On Jun 27, 2013, at 1:49 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 27 June 2013 10:44, plantec <alain.plantec(a)yahoo.com> wrote: >> Hi all, >> The current hand has the world as its owner but the world >> submorphs do not contains the current hand. >> Why is it like that ? > > i do not think you will get the answer to your question here, because i think > most people here are clueless as well as you. > > World knows about its hands via > world->state->hands. > > If you look at HandMorph, it mixes a lot of roles together, including: > - as a visual object (morph) which displaying mouse pointer > - as an entry pont for dispatching events down to separate morphs > > theoretically, it could be nice to have two separate obejcts for those roles, > one of them can indeed be just a morph, and contained in world but not > the other one. yes we will start to work on that with fernando. > > > -- > Best regards, > Igor Stasenko. >

June 27, 2013

Re: [Pharo-dev] question about HandMorph

by Igor Stasenko

On 27 June 2013 10:44, plantec <alain.plantec(a)yahoo.com> wrote: > Hi all, > The current hand has the world as its owner but the world > submorphs do not contains the current hand. > Why is it like that ? i do not think you will get the answer to your question here, because i think most people here are clueless as well as you. World knows about its hands via world->state->hands. If you look at HandMorph, it mixes a lot of roles together, including: - as a visual object (morph) which displaying mouse pointer - as an entry pont for dispatching events down to separate morphs theoretically, it could be nice to have two separate obejcts for those roles, one of them can indeed be just a morph, and contained in world but not the other one. -- Best regards, Igor Stasenko.

June 27, 2013

Re: [Pharo-dev] Metacello doubt

by Igor Stasenko

Just adding some comments: - i avoid using loading bleeding edge because it has problems which only humans can solve: - if there are two different branches, not yet merged it may load not one that you want - even if dependencies is ok, it doesn't means that if you load two latest versions of two packages, they will work so, what i do, is loading a known working config, and then go to monticello and manually picking and loading updated packages. On 27 June 2013 01:27, Dale K. Henrichs <dale.henrichs(a)gemtalksystems.com> wrote: > > > ________________________________ > > From: "Guido Chari" <charig(a)gmail.com> > > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Sent: Wednesday, June 26, 2013 2:49:09 PM > Subject: Re: [Pharo-dev] Metacello doubt > > I understood. Thanks for the answer Dale. The drawback in this case is to > specify a particular dependency to AsmJit in my configuration. Also, perhaps > is the right way since i realized i have a particular dependency on it. > > But this discussion makes me thing a little and so i have a new question. > > Form what I (mis) undestand from Metacello, when asking for a bleedingEdge > version it loads only the baseline that specifies packages and then last > version of every package specified there. > > As in the projects referenced on the baseline there is no need for > specifying a version, and that's the case of nativeBoost configuration, > wouldn't it be interesting to have some behavior (i mean i new method for > loading like loadDeepSymbolic:) that not only load the symbolicVersion of > the package asked, but also propagate that symbolicVersion (bleedingEdge in > this case) to all the dependencies that don't specify a concrete version? > > Guido. > > Guido, > > With the Metacello Scripting API[1] I've taken a slightly different tack, > but I think that it gets you to the same place. > > I am a big fan of deterministic loads, but I know that from a practical > point of view developers need to have a certain amount of control over > exactly what gets loaded into their DEVELOPMENT environments and they need > to be able to exert this control without having to resort to editing > configurations to match their specific requirements. > > I have accomplished this by arranging for a Notification to be signalled > whenever a project is referenced during a load. The developer can use one or > more of the onUpgrade:, onDowngrade: and onConflict: clauses in their load > scripts to exert fine control over what happens on a project by project > basis ... > > For your specific use case, I would think that you would want to use the > `lock` command[2] and specify that you want to `lock` the projects > (NativeBoost and AsmJit) to the #bleedingEdge version. I don't recall if > I've got test cases for symbolic versions, but if you are seriously > interested in taking the Scripting API for a spin, I'd be willing to write > some additional tests using the #bleedingEdge symbolic version (if not > already covered) and validate this use case... > > I am entering a phase where I will be doing some work on getting FileTree > and Metacello up to snuff for Pharo3.0 so this would be a good time for me > to add some test cases in anticipation of having some interested users ... > > I haven't released the Scripting API, because I need to have real users with > real use cases take the API for a spin and validate the API. The Scripting > API can be loaded into any version of Pharo/Squeak/GemStone and I think the > Scripting API is (or will be) available in Pharo3.0. > > I'm looking forward to getting feedback as to how the API stands up to real > use ... > > So let me know if you are interested in being another Scripting API guinea > pig:) > > Dale > > [1] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… > [2] > https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUse… -- Best regards, Igor Stasenko.

June 27, 2013

Re: [Pharo-dev] [Pharo-project] Understanding NBOpenGL

by kilon

According to the 2.1 reference in opengl website http://www.opengl.org/sdk/docs/man2/ <http://www.opengl.org/sdk/docs/man2/> glShaderSource I have to pass an array of pointers that point to the strings that make the shader's source. Question is does NBExternalAdress fromString: shaderString , does that ? If no, how I create an array of pointers from a single string ? It looks like that the call itself fails because nativeboost does not like how I call the function, so that explains why I get no opengl error. -- View this message in context: http://forum.world.st/Understanding-NBOpenGL-tp4686514p4695614.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

June 27, 2013

Re: [Pharo-dev] NBGLFrameBuffer>>checkStatus

by Igor Stasenko

On 26 June 2013 21:06, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Apparently, it happens that we get an error "Frame buffer status: Unknown error". The error comes from the method checkStatus: > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > NBGLFrameBuffer>>checkStatus > | status | > self bind. > status := gl checkFramebufferStatusEXT: GL_FRAMEBUFFER. > > status = GL_FRAMEBUFFER_COMPLETE ifFalse: [ > #( > #GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT > #GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT > #GL_FRAMEBUFFER_INCOMPLETE_DRAW_BUFFER > #GL_FRAMEBUFFER_INCOMPLETE_READ_BUFFER > #GL_FRAMEBUFFER_UNSUPPORTED > #GL_FRAMEBUFFER_INCOMPLETE_MULTISAMPLE > #GL_FRAMEBUFFER_UNDEFINED > ) do: [:sym | > (self class bindingOf: sym) ifNotNil: [:b | > status = b value ifTrue: [ ^ self error: 'Frame buffer is incomplete: ', b key ] ]. > ]. > ^ self error: 'Frame buffer status: Unknown error'. > ]. > ^ true "ok" > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Any idea what's going on? > > We took a Pharo 2.0, loaded Athens, NBOpenGL, SourceCity, and roassal3d. Running the test of roassal3d shows this. > I suspect this error comes from some interaction between the tests. Closing an opengl window is enough to desallocate the opengl resources? > If i remember , you should close and force GC. But of course, it would be preferable , if on window close event you explicitly deallocate things immediately, then you don't have to wait for GC to clean it for you. The problem, i think, is interference between two different opengl contexts. OpenGL is built so, that you need to actiave different context (glMakeCurrent) between using any functions for it (otherwise you would need to pass extra argument - a context handle, to each function).. Now i think the code that allocates/deallocates things in opengl assumes that a valid context is currently selected (or only single context ).. because apparently, if current context is different than where you did allocated the resources , you will get an error. > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > -- Best regards, Igor Stasenko.

June 27, 2013

[regression reporter]regression occurred

by no-reply＠ci.inria.fr

https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-2-Validation/./label=li… 2 regressions found. KernelTests.Numbers.NumberTest.testUnCategorizedMethods CollectionsTests.Strings.StringTest.testAt

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Goubier Thierry

Le 27/06/2013 10:46, Frank Shearar a Ã©crit : > On 27 June 2013 09:49, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >> >> Le 27/06/2013 10:30, Camillo Bruni a Ã©crit : >>> >>> >>> On 2013-06-27, at 10:32, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >>> >>>> >>>> >>>> Le 27/06/2013 10:14, Camillo Bruni a Ã©crit : >>>>>>>> >>>>>>>> >>>>>> >>>>>> I like the fact that I can do git log --pretty="%H" >>>>>> path_to_method_file, and I have all the hashes I need. >>>>> >>>>> >>>>> yeah but you have the "wrong" hash as the source includes the category >>>>> :) >>>>> I prefer storing the methods in subfolders which represent categories, >>>>> so I keep >>>>> the methods sources as clean as possible. For instance this way a >>>>> recategorization >>>>> is detected as a move by standard git tools. Now that I say, we should >>>>> do the same >>>>> for the classes :P. >>>> >>>> >>>> In this case, how would you query git for all the versions of a method? >>>> If it is recategorized, you would not be able to see through the move, no? >>> >>> >>> if you store the category in the method you won't see a move of course, >>> otherwise yes: >>> >>> >>> https://github.com/pharo-project/pharo-core/commit/4383816cd432229a9977cfbe… >> >> >> I still have a worry with that, because I don't see how to load a method >> version previous to the change (except with a lot of code to understand it >> image side). >> >> When I scan for method versions, I do, given a commitID, get the method + >> metadata. If the method path is dependent on which commitID I select, it >> becomes significantly more complex. > > Why not just have a directory for the methods, and a single metadata > file for categorising methods? We've talked on and off over the years > about turning categories into tags (so a method could be in multiple > categories), which this would allow. It would _also_ mean that > recategorising a method wouldn't touch the file containing the method. Yes! I want more of that kind of suggestions :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2013

Re: [Pharo-dev] Versions Browser over gitfiletree://

by Goubier Thierry

Le 27/06/2013 11:19, StÃ©phane Ducasse a Ã©crit : > > On Jun 27, 2013, at 9:54 AM, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > >> >> >> Le 27/06/2013 09:39, StÃ©phane Ducasse a Ã©crit : >>> >>>> It's tempting because it seems to solve long running irritations I had with Smalltalk development (from many years ago); the need to keep the same image (saving and saving again) to maintain the development context, and being at the mercy of memory leaks, lack of stability, updates trashing my development image, etc :( >>>> >>>> With that kind of git support, I can change my workflow to: save frequently my packages, rm the image, package-cache and all the junk, and rebuilt everything from get.pharo.org and the git repos... Thanks to the pharo command line improvements as well :) >>> >>> But I save regularly on MC server or locally (after each new read and green tests is a good moment) >>> Because having git as a backend will not give you micro commit. >> >> Yes and no. You could have micro commit, it's dead easy to implement. >> >>> Then we are working on a really nice code modification logging named EPICEA to replace the old cs. >>> Because if you crash your image between two git commit. >> >> Micro-commit can be implemented on MC over git. It's a easy deal if you need it. >> >> I'm sure EPICEA will improve over the old cs format. Will that make it better than improving the package infrastructure? I'm not so sure. > > this is not related. > the source code management right now mixes > source code > log of modification. What you see in the git use is that you have to mix the two anyway. If you don't, the git users will adjust the file format so that git detect automagically the modifications (i.e. recreate the log) that you haven't written in :-P > EPICEA is about replacing the recovering crash kind of the tool (and more of course) > but it is not about source. And I hope EPICEA will help in handling source versionning :) Thierry > > > >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

June 27, 2013

Re: [Pharo-dev] [ENH]: Window Menu Registration (like World Menu)

by StÃ©phane Ducasse

yes because we are busy. Busy does not mean that we are not interested. > Nobody has looked at this in 10 days... > > > On Jun 17, 2013, at 2:12 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > >> Sean P. DeNigris wrote >>> https://pharo.fogbugz.com/f/cases/10910/Window-Menu-Registration-like-World… >> >> New fix in inbox: >> SLICE-Issue-10910-Window-Menu-Registration-like-World-Menu-SeanDeNigris.3 >> >> This version: >> * FallbackMenu: reset the builder after debugging, or the fallback menu does >> not appear anymore (e.g. the next time the pragma menu tries to build >> itself) >> >> From version 2: >> * Remove DiscoveredMenu >> * Move most menu building logic into PragmaMenuBuilder. Now we have fallback >> menus for all buildl menus! e.g. Nautilus menus >> * Leave a #fallbackMenuOn: hook in Object (packaged with PragmaMenuBuilder), >> where custom fallback items can be added. I didn't want to do it with >> pragmas in case we ended up with neither the discovered or fallback working >> * Class comment for FallbackMenu. Thanks Cami for the review :) >> * PragmaMenuBuilder - don't #buildTree during instance creation. Wait until >> necessary (i.e. when a menu spec is built). This makes it nice and clean to >> trap all errors when the spec is built and throw up a fallback menu >> >> From version 1: >> * Use annotation <windowMenu> >> * Re-implement existing menu options with pragma/builder >> * Refactor general menu discovery code common to both World and Window menus >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/ENH-Window-Menu-Registration-like-World-Menu-tp469326… >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >

June 27, 2013