- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Gofer issue

by Lukas Renggli

> however, Â if i open the MC repo browser, it clearly shows that most > recent version is > CMakeVMMaker-Igor.Stasenko.16 Â (at the moment of writing this message) Following the coventions your name is 'Igor' and the package is on the branch 'Stasenko'. Gofer proritizes the main branch. > Gofer new > Â Â Â url: 'http://squeaksource.com/VMMaker'; > Â Â Â package: 'VMMaker-oscog.46'; > Â Â Â load. > > and it barks that given version is not found.. which of course not true. 'VMMaker-oscar.46' is clearly not a package name, use #version: to refer to a specific version. > Actually i surprised that Gofer simply don't reusing the MC package > enumeration logic.. or maybe it does.. but obviously doing it wrong :) Please study the documentation in the class comment of Gofer. Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 20, 2011

Re: [Pharo-project] Using AlienOpenGL

by Schwab,Wilhelm K

Not that you are wrong, but how did you choose AlienOpenGL over CroquetGL? IIRC, there is also a 3D project associated with NativeBoost. The latter lives here: http://code.google.com/p/nativeboost/ Just curious. I was originally very disappointed that Croquet was an all-or-nothing proposition. Just studying the code, it had a very nice way of manipulating 3D objects (more than just drawing triangles), but it was part of the 3D operating system, which was not something I could put in front of the end users I had in mind. Here's hoping the nice code is moving toward something that we can use to open 3D views from inside of Pharo. On to your debugging problem, can you tell what Pharo is trying to load? I have resorted to building my own VM to get a look at exactly what paths are used to load libraries. Even a relevant #moduleName return value might help identify the required library. You could be experiencing problems because the library is not present, or because FFI is looking in the wrong place. The Linux VM does not easily give up its secrets. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Ricardo Jacas [ricardo.jacas(a)gmail.com] Sent: Thursday, January 20, 2011 1:44 PM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Using AlienOpenGL hi, im trying to work with the AlienOpenGL library, in ubuntu, but i cant get even the test to run. it keeps saying i dont have a basic library but i dont have a clue how to get it. i have been all day ready post about it and i simply cant make it. anyone can do a stupid proof guide? Ricardo -- lets reign all together

Jan. 20, 2011

[Pharo-project] Gofer issue

by Igor Stasenko

Hello, Gofer doesn't likes my package naming :( When i use: Gofer new url: 'http://squeaksource.com/VMMaker'; package: 'CMakeVMMaker'; load. it loads the CMakeVMMaker-EstebanLorenzano.15 however, if i open the MC repo browser, it clearly shows that most recent version is CMakeVMMaker-Igor.Stasenko.16 (at the moment of writing this message) which means that Gofer package name/version parsing logic are not in sync with MC. Same applies to VMMaker-oscog.. Tried to do: Gofer new url: 'http://squeaksource.com/VMMaker'; package: 'VMMaker-oscog.46'; load. and it barks that given version is not found.. which of course not true. Actually i surprised that Gofer simply don't reusing the MC package enumeration logic.. or maybe it does.. but obviously doing it wrong :) -- Best regards, Igor Stasenko AKA sig.

Jan. 20, 2011

Re: [Pharo-project] Issue 3560 in pharo: Clean of RML

by pharo＠googlecode.com

Updates: Labels: Milestone-1.2 Milestone-1.3 Comment #1 on issue 3560 by marcus.d...(a)gmail.com: Clean of RML http://code.google.com/p/pharo/issues/detail?id=3560 (No comment was entered for this change.)

Jan. 20, 2011

Re: [Pharo-project] Issue 1426 in pharo: Auto completion does not complete symbols

by pharo＠googlecode.com

Comment #8 on issue 1426 by DVCio...(a)gmail.com: Auto completion does not complete symbols http://code.google.com/p/pharo/issues/detail?id=1426 I can confirm this behaviour in dev 1.2rc1 12311, yet some clarification is needed for proper functioning: #od is taken as a literal symbol, similar to #ev, and have no auto-completion. ##od gives the suggestion for odd because ## is evaluated first to literal symbol and od is then used for auto-completion. 'od' with cursor before closing ' gives auto-completion [od] does not; nor does (od) Since I'm new, which should produce the auto-completion and which shouldn't?

Jan. 20, 2011

[Pharo-project] Using AlienOpenGL

by Ricardo Jacas

hi, im trying to work with the AlienOpenGL library, in ubuntu, but i cant get even the test to run. it keeps saying i dont have a basic library but i dont have a clue how to get it. i have been all day ready post about it and i simply cant make it. anyone can do a stupid proof guide? Ricardo -- lets reign all together

Jan. 20, 2011

Re: [Pharo-project] Hapao for Test coverage!

by Alexandre Bergel

Hi Lukas! You made good points. We will fix them. Thanks for these feedback. Cheers, Alexandre On 20 Jan 2011, at 15:14, Lukas Renggli wrote: > Very cool. > > I encountered two problems when trying the ready-made image on the > packages 'PetitParser' and 'PetitTest': > > 1. In Profiler>>#runningUnitTests:atEachTestEvaluate: the message > #selector is not understood by TestSuite. It worked after I commented > "Transcript show: t selector; cr." and "(self testMethodsToIgnore > includes: t selector)". > > 2. There is a bug with package extensions: Hapao considers extension > methods that are not part of the selected packages as not covered and > also displays them in the visualization. This is misleading and gives > wrong results for '% coverage'. > > Lukas > > On 20 January 2011 09:41, Vanessa PeÃ±a <vane.c.pena(a)gmail.com> wrote: >> Hello all, >> >> We are happy to introduce you Hapao, an innovative test coverage tool which >> gives you an intuitive graphical representation to visually assess the >> quality of the coverage. >> >> For more information and download you can visit us at: >> http://hapao.dcc.uchile.cl/ >> Of course, all feedback is always welcome :) >> >> Have fun! >> The Hapao Team. >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 20, 2011

Re: [Pharo-project] Hapao for Test coverage!

by Lukas Renggli

Very cool. I encountered two problems when trying the ready-made image on the packages 'PetitParser' and 'PetitTest': 1. In Profiler>>#runningUnitTests:atEachTestEvaluate: the message #selector is not understood by TestSuite. It worked after I commented "Transcript show: t selector; cr." and "(self testMethodsToIgnore includes: t selector)". 2. There is a bug with package extensions: Hapao considers extension methods that are not part of the selected packages as not covered and also displays them in the visualization. This is misleading and gives wrong results for '% coverage'. Lukas On 20 January 2011 09:41, Vanessa PeÃ±a <vane.c.pena(a)gmail.com> wrote: > Hello all, > > We are happy to introduce you Hapao, an innovative test coverage tool which > gives you an intuitive graphical representation to visually assess the > quality of the coverage. > > For more information and download you can visit us at: > http://hapao.dcc.uchile.cl/ > Of course, all feedback is always welcome :) > > Have fun! > The Hapao Team. > > -- Lukas Renggli www.lukas-renggli.ch

Jan. 20, 2011

Re: [Pharo-project] About XML Support in the 1.2

by Dale Henrichs

On 01/19/2011 11:37 PM, Norbert Hartl wrote: > > On 19.01.2011, at 19:01, Dale Henrichs wrote: > >> I think that the a good working model is to store the >> ConfigurationOfXXX in the project repository along with the >> project mcz files. >> >> When a new version is released the configuration should be copied >> to MetacelloRepository for the Pharo and Squeak community. I have >> a GemSource MetacelloRepository where I put copies of >> configurations that have been ported to GemStone .... when a new >> version for GemStone is available. >> >> I would not recommend that configurations be removed from >> MetacelloRepository as that could break existing configurations >> that expect to find the configuration there. So if it is found >> that there are out-of-date configurations in MetacelloRepository, a >> new version of the configuration should be copied into >> MetacelloRepository. >> >> Now that Metacello is more established, I don't think that it is >> critical to require that all configurations be copied to >> MetacelloRepository. >> >> It still is useful to have a sort of clearinghouse for >> configurations and until a better solution comes along it serves >> that purpose. BTW, I think Stef has plans to provide better >> solutions for Pharo... >> > I understand what you are saying and I partially agree. But it just > doesn't feel right and this is easy to show. In this example of > ConfigurationOfXMLSupport there was not one caring person like you > are that does everything and has on overview. There is a > Configuration in MetacelloRepository than it was decided to keep the > main Configuration file in XMLSupport repository. Development took > place in the XMLSupport repository. In the meantime someone changed > the Configuration in MetacelloRepsository probably for integration > purposes. Now the Configuration has been copied from XMLSupport and > has overwritten the changes that have been made to the existing > Configuration. That is what you get if you branch off things. > > I don't know how to solve this properly because I didn't have time > to follow the metacello discussions. But if there is a possibility > to specify the stable for pharo 1.1.1 that doesn't change even if > the packages evolves I can't see much reason to have a writable > version of the Configuration in MetacelloRepository. > > Norbert I understand that there are potential problems using distributed version control, but one of the reasons that I chose to use code for specifying Metacello configurations is thatit made it possible to use Monticello merge facilities to reconcile changes mad in different branches ... This was a breakdown in procedure ... the intent of MetacelloRepository is not to create branches of configurations...if I recall, there was a change in the developers that coincided with the creation of metacello configurations ... I would hope that this case be classed as a learning experience rather than a condemnation of process. I agree that there could be a better way, but I think that the better way involves tools support and until we get the tools we must resort to process ... Dale >> >> >> On 01/19/2011 06:12 AM, laurent laffont wrote: >>> On Wed, Jan 19, 2011 at 2:49 PM, Norbert Hartl<norbert(a)hartl.name >>> <mailto:norbert@hartl.name>> wrote: >>> >>> >>> On 19.01.2011, at 14:30, laurent laffont wrote: >>> >>>> On Wed, Jan 19, 2011 at 1:37 PM, Norbert >>>> Hartl<norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >>>> >>>> It depends where you look at. ConfigurationOfXMLSupport exists >>>> in MetacelloRepository as well as in XMLSupport. The latter >>>> one being the official one, the former one being very outdated. >>>> My sugesstion would be to remove ConfigurationOfXMLSupport >>>> from MetacelloRepository to lower the confusion. >>>> >>>> >>>> Personnally I always look in MetacelloRepository, this should >>>> be the reference IMHO. >>>> >>> Laurent, >>> >>> I think it is up to the maintainers where to put those files. >>> And in the XMLSupport case the decision was made deliberately not >>> to put it in MetacelloRepository but in XMLSupport. The only >>> thing I want to avoid is having multiple different files floating >>> around that are edited in an inconsistent way. >>> >>> >>> I thought that all ConfigurationOfXXX working for Pharo should >>> be put in MetacelloRepository so we have a central place to look >>> at. >>> >>> But I may be wrong. Mariano ? Dale ? >>> >>> Laurent >>> >>> >>> Norbert >>> >>>> >>>> Norbert >>>> >>>> On 19.01.2011, at 13:18, Tudor Girba wrote: >>>> >>>>> The last version 1.1.6 is marked as #release. >>>>> >>>>> Cheers, Doru >>>>> >>>>> >>>>> On 19 Jan 2011, at 12:26, laurent laffont wrote: >>>>> >>>>>> I put ConfigurationOfXMLSupport version 1.0 because >>>> blessing was #release. But I agree to change. >>>>>> >>>>>> Laurent >>>>>> >>>>>> On Wed, Jan 19, 2011 at 12:15 PM, Marcus Denker >>>> <marcus.denker(a)inria.fr<mailto:marcus.denker@inria.fr>> wrote: >>>>>> >>>>>> On Jan 19, 2011, at 11:43 AM, Tudor Girba wrote: >>>>>> >>>>>>> Indeed, this is a problem for Moose in general. We >>>>>>> depend >>>> on XMLSupport, but now we cannot update it in PharoDev. I >>>> would also strongly support the idea of removing XMLSupport >>>> from PharoDev. >>>>>>> >>>>>> >>>>>> What would be important: we need the latest version in >>>> Pharo 1.2... else how can we ever have a version where the >>>> tests are green? >>>>>> (not of XML, but in general) >>>>>> >>>>>> Marcus >>>>>> >>>>>>> Cheers, Doru >>>>>>> >>>>>>> >>>>>>> On 19 Jan 2011, at 11:32, Fabrizio Perin wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I have a problem with the XMLSupport version from >>>>>>>> Pharo 1.2. >>>>>>>> >>>>>>>> The problem is that I need to work with one of the >>>>>>>> last >>>> version of XMLSupport but in the pharo image 1.2 is loaded an >>>> old version of XMLSupport (I mean a version from Jan 2010). I >>>> did try to load a newer version of XMLSupport using >>>> ConfigurationOfXMLSupport but some errors make this operation >>>> impossible. >>>>>>>> So either Pharo-dev 1.2 load a newer (possibly the >>>>>>>> last) >>>> version of XMLSupport by default or Pharo-dev 1.2 should not >>>> load XMLSupport at all. >>>>>>>> >>>>>>>> I think that doesn't make sense to use by default such >>>>>>>> an >>>> old version, also considering that the last XMLSupport has >>>> nice and useful features like the XMLPluggableElementFactory. >>>>>>>> >>>>>>>> By avoiding to load XMLSupport in Pharo-dev 1.2 by >>>> default you let people free to use the version that they like. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Fabrizio >>>>>>>> >>>>>>> >>>>>>> -- www.tudorgirba.com<http://www.tudorgirba.com/> >>>>>>> >>>>>>> "We cannot reach the flow of things unless we let go." >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- Marcus Denker -- http://www.marcusdenker.de >>>> <http://www.marcusdenker.de/> >>>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- www.tudorgirba.com<http://www.tudorgirba.com/> >>>>> >>>>> "If you interrupt the barber while he is cutting your hair, >>>>> you will end up with a messy haircut." >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > >

Jan. 20, 2011

Re: [Pharo-project] Issue 3527 in pharo: Please add the following Generator code to Pharo. I need it to port a package I am writing from Squeak to Pharo

by pharo＠googlecode.com

Comment #2 on issue 3527 by rpbol...(a)gmail.com: Please add the following Generator code to Pharo. I need it to port a package I am writing from Squeak to Pharo http://code.google.com/p/pharo/issues/detail?id=3527 I thought I had attached two files. Be that as it may I have attached the generator file again below Attachments: Generator.st 3.7 KB

Jan. 20, 2011