- Pharo-dev - lists.pharo.org

[Pharo-project] Nautilus & Trats

by Igor Stasenko

Hi, i have many DNU's when working with Nautilus and coding traits.. - browsing trait's class side -> DNU - changing/adding new methods -> DNU please check that -- Best regards, Igor Stasenko.

June 10, 2012

[Pharo-project] Enhancement - version history to include class and method renames

by Ben Coman

Since <Versions> shows both the class name and method name, it would be useful to have class and method renames to have that show up in the version history. Use case: 1. PersonA creates a ClassA and methodA. <Versions> shows the author of ClassA>methodA as PersonA. 2. PersonB renames classA to classB. <Versions> shows the author of ClassB>methodA as PersonA. Where as I think the guilty party should show as PersonB. cheers -ben

June 10, 2012

Re: [Pharo-project] DBXTalk code changes / band-aides

by Cam S

After yet another search of the forums, this time I think I struck gold: I found this tidbit... Gofer new renggli: 'magritte3'; package: 'Magritte-Model'; package: 'Magritte-Pharo-Model'; package: 'Magritte-Seaside'; package: 'Magritte-Pharo-Seaside'; package: 'Magritte-Morph'; package: 'Magritte-Tests-Model'; package: 'Magritte-Tests-Pharo-Model'; load. Doing that, it looks like there is sanity in the asComponent method. I am testing it now. (It as a March posting...) -cam

June 10, 2012

[Pharo-project] DBXTalk code changes / band-aides

by Cam S

> > >>> > >> I have a few fixes for DBXTalk: the Magritte descriptions generation (I >>> switched Array output code-generation to the {...} format instead of #( >>> ...) which was not allowing #conditions: to be properly formatted, which >>> may be a problem for other smalltalk environments), and other trivial fixes. >>> >> > Excellent!!! :) Thanks. Can you send us the changes or directly commit? > Band-aide approach... DBXMagritteWriterVisitor>>writeDescription: aMADescription onClass: aClass | properties descriptionMethod classes | properties := '; ' join: (aMADescription properties associations collect: [ :assoc | '{1}: {2}' format: {(assoc key). "assoc value printString" ((assoc value isKindOf: Array) ifTrue: ['{', ('. ' join: assoc value ), '}' ] ifFalse: [ assoc value printString ])} ]). ... - <clipped> Mine is a horrible solution. Given that there are blocks in the conditions loops, the traditional array notation, #( ... ), will not work anyway, so the curly-brace approach is fine. I played around with #respondsTo: and tried to generalize, but hit problems because the value is often a symbol or string. so in the end, to get my classes generated, I just did the above quick-n-dirty patch. The only other changes I have gone ahead and made were to make certain that more methods of DBXEntity return the newly created attribute/entity, so that I could say something like the following: (e hasOne: #DpAddress as: #mailingAddress) label: 'Mailing Address'; priority: 400. So all of the #hasOne:as:, #hasMany:as:, etc. .... Oops... looks like late last night, when I was updating packages to see if i was missing anything, I lost my changes to those methods! There were only 4 or 5 such changes, and they were trivial. Cheers. I like the DBXTalk approach. And Magritte too. In the two major projects I worked on over the years, and even on a couple of small side projects, I/we ended up using meta-language tools to add runtime behavior; and the starting code for new objects, at least in the one big project, was generated from a short-hand table of the meta-language specs. Very powerful. And lazy people like me are drawn to such things. Nice work guys! Cam

June 10, 2012

Re: [Pharo-project] [Pharo-users] loading order for seaside / DBXTalk + Magritte / Pharo 1.4 / configuration

by Cam S

> > I keep having problems with configurations. The documentation for each >>>> particular tool looks so simple, and seems to work all by itself, but for >>>> some reason, I keep failing at having one 1.4 (or 1.3) image where >>>> everything works (e.g. Glorp AND seaside AND DBXTalk); though I do have 3 >>>> different images where 2-out of three work, so by revolving my dev process >>>> through the images, >>>> >>> >> > what is *exactly* what does not work? otherwise we cannot guess. >> > Like Object instance>>#description, which prevents asComponent from working, in the currently configured 1.4 image I am working with. If I change the behavior there, I run into other problems. Other problems in other images with different load orders. I was not expecting anyone to guess. I was just wondering whether anyone has actually made them all work together or not. If not, then I do not have time to be the one to battle through it. Same old story: I simply do not have time. - I will go through the load process again, keeping it minimal, and provide the scripts (workspace contents) back on this list. I have a few fixes for DBXTalk: the Magritte descriptions generation (I >>>> switched Array output code-generation to the {...} format instead of #( >>>> ...) which was not allowing #conditions: to be properly formatted, which >>>> may be a problem for other smalltalk environments), and other trivial fixes. >>>> >>> >> Excellent!!! :) Thanks. Can you send us the changes or directly commit? >> > Sure, I would rather not commit them without someone else reviewing them. Does the {} array notation work in any flavors of smalltalk other than Pharo? Thanks, I will get back to you... after I go through this process again. -Cam

June 9, 2012

[Pharo-project] Jenkins 502 errors

by Sean P. DeNigris

I found this mailing list post [1] recommending this [2] and this [3] for 502 errors... don't know if it's related to our problem... HTH, Sean [1] http://permalink.gmane.org/gmane.comp.java.hudson.user/39500 [2] http://stackoverflow.com/questions/163603/apache-sockets-not-closing [3] https://wiki.jenkins-ci.org/display/JENKINS/Running+Jenkins+behind+Apache -- View this message in context: http://forum.world.st/Jenkins-502-errors-tp4634147.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 9, 2012

Re: [Pharo-project] [Pharo-users] Fuel FLMethodChanged error

by Mariano Martinez Peck

> >> >> After loading FuelMetaLevel as Martin suggested the above code works to >> serialize and materialize the problematic domain objects just fine. >> > > Ok, just to clarify: when you install the package Fuel only, and in your > graph you have entities like classes or methods, they will be considered > "global", that is, we just store the class name and selector and during > materialization we search it in the Smalltalk globals. If the class/method > is not present, we throw an error. Now...closures are more complicated > because you can even EVALUATE them. If the method surrounding the closure > has changed in the image you are materializing, evaluating the closure > (depending on the change in the method) can even crash your VM. Because of > that, when serializing methods "as globals" we also store a chemsum and we > compare during materialization to see that it hasn't change it. If changed, > we throw the FLMethodChanged. > With the package FuelMetalevel, and by using #newFull the serializer will > consider the method as "full" so it will be fully serialized, and therefore > you don't have the problem of the checksum. > > Anyway, you found a bug because you should not be needing FuelMetalevel > since you are serializing and materializing in the same image. > > Ok...the problem was when you are using the normal (light) serialization with Fuel where methods are always serialized as global. In your case, the method was "not installed" and therefore, was different during materialization. I have just commited Fuel-MarianoMartinezPeck.695. If you know try to serialize again your example, you should get a FLNotInstalledMethod error saying " #XXXSelector can not be serialized as global because it is not installed. You need FuelMetalevel to fully serialize methods. See the documentation. '" And now in http://rmod.lille.inria.fr/web/pier/software/Fuel/Errors I have added that exception and its explanation: * ** FLNotInstalledMethod** By default, Fuel serializes methods as globals. For more details see this page<http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/…>. I am an error produced during serialization, signaled when trying to serialize a method that is not installed in any class. It is a prevention, because such method is lekely to be absent during materialization. This case may happen when serializing closures that hold references to not installed methods. If the user wants to fully serialize methods, then it needs to install the package FuelMetalevel (see this page for explanations<http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/…>) and create the serializer by using the method #newFull. Example:* * FLSerializer newFull serialize: anObject toFileNamed: 'example'.* Cheers > We will investigate it. > > Thanks > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

June 9, 2012

[Pharo-project] [update 2.0] #20122

by StÃ©phane Ducasse

20122 ----- - Issue 6044: Nautilus Method Rename. Thanks Benjamin van Ryseghem. http://code.google.com/p/pharo/issues/detail?id=6044 - Issue 5487: Deferring the calculation of the failure description string in TestCases. Thanks Stefan Marr. http://code.google.com/p/pharo/issues/detail?id=5487 + cleaning all hardcoded references to TestResult, TestResource and TestSuite. - Issue 6049: Monticello Browser repository List and repositories out of sync when searching. Thanks Dan Uber. http://code.google.com/p/pharo/issues/detail?id=6049

June 9, 2012

Re: [Pharo-project] [Pharo-users] loading order for seaside / DBXTalk + Magritte / Pharo 1.4 / configuration

by Sean P. DeNigris

Guillermo Polito wrote > > Actually, nabble forum is kind of read only. If you post in there, the > messages are not forwarded to the mailing list. The messages will be forwarded if you are subscribed to the underlying list. Join the DBXTalk group at https://groups.google.com/forum/#!forum/dbxtalk and you will be able to post through either google or nabble. Sean -- View this message in context: http://forum.world.st/Re-Pharo-users-loading-order-for-seaside-DBXTalk-Magr… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 9, 2012

Re: [Pharo-project] [Pharo-users] loading order for seaside / DBXTalk + Magritte / Pharo 1.4 / configuration

by Guillermo Polito

On Sat, Jun 9, 2012 at 11:05 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Sat, Jun 9, 2012 at 9:58 PM, Cameron Sanders <camsanders(a)aol.com>wrote: > >> >> >> On Sat, Jun 9, 2012 at 3:39 PM, Cameron Sanders < >> csanders(a)debrispublishing.com> wrote: >> >>> I keep having problems with configurations. The documentation for each >>> particular tool looks so simple, and seems to work all by itself, but for >>> some reason, I keep failing at having one 1.4 (or 1.3) image where >>> everything works (e.g. Glorp AND seaside AND DBXTalk); though I do have 3 >>> different images where 2-out of three work, so by revolving my dev process >>> through the images, >>> >> > what is *exactly* what does not work? otherwise we cannot guess. > > > >> I can make headway... but there must be a better way. Especially given >>> that those images contain different versions of the tools and core image. >>> >>> > I don't use Seaside. Why don't you provide the whole gofer script you use > to install those 3 tools so that someone can reproduce it? > > >> Is there someone who has all three tools (Glorp, DBXTalk & Magritte, and >>> Seaside) coexisting and playing well together in a 1.4 (or 1.3) image? >>> Could you please drop me an email? >>> >>> > I attach the Pharo development mailing list. > > > >> I also want to use Fuel for some things. >>> >>> How much money would I need to donate to Pharo per year, so that the >>> recipients would make available an image meeting my (see above) specs with >>> the recommended patterns working? With updates available every 3 months, >>> for example. >>> >> >> [if i pay for something, deducting the money from my taxable income is no >> problem.] >> >>> >>> I am sure there are a few common configurations that people would like. >>> Part of the problem of course is the explosion of tools! Nice work >>> everybody!! >>> - >>> >>> Who would be the DBXTalk expert? >>> >> > Me, Guillermo Polito, Esteban Lorenzano and many others. > > >> For some reason I am unable to post on the nabble forum -- oddly, a >>> private thread of emails I shared with Pamela ended up there, but I cannot >>> seem to post directly. I keep trying to join, but nabble never lets me in. >>> [I must be making another stupid mistake...] >>> >>> > We didn't receive any email from you. Yuo should register in this google > group: http://groups.google.com/group/dbxtalk/?pli=1 > Actually, nabble forum is kind of read only. If you post in there, the messages are not forwarded to the mailing list. Here are other links of interesting resources: http://dbxtalk.smallworks.com.ar/Support/?_s=sl3ptC0z84u54Hyk&_k=y49B2OsTLC… > > >> I have a few fixes for DBXTalk: the Magritte descriptions generation (I >>> switched Array output code-generation to the {...} format instead of #( >>> ...) which was not allowing #conditions: to be properly formatted, which >>> may be a problem for other smalltalk environments), and other trivial fixes. >>> >> > Excellent!!! :) Thanks. Can you send us the changes or directly commit? > > >> - >>> Any help or guidance you can provide is most welcome! >>> >>> -Cam Sanders >>> 603-412-2134 >>> PS: any pharo smalltalkers right here in New Hampshire, USA? >>> >>> > > > -- > Mariano > http://marianopeck.wordpress.com > >

June 9, 2012