June 2012 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Versionner a GUI for metacello

by Sean P. DeNigris

Benjamin Van Ryseghem-2 wrote > > Spec is working in Pharo1.4 without any problem (it's actually used by > nautilus :) ) > > In addition, I would say that Spec has been designed in a way it can be > easily plugged on top of any graphical library :) > Excellent - full retraction ;-) -- View this message in context: http://forum.world.st/Versionner-a-GUI-for-metacello-tp4607220p4634169.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 10, 2012

Re: [Pharo-users] Versionner a GUI for metacello

by Benjamin

Spec is working in Pharo1.4 without any problem (it's actually used by nautilus :) ) In addition, I would say that Spec has been designed in a way it can be easily plugged on top of any graphical library :) Ben On Jun 9, 2012, at 11:35 PM, Sean P. DeNigris wrote: > > Juan Pablo Sandoval wrote >> >> As Stef wrote, I am working in a Spec version of Versionner :) > > I'm wondering whether using spec this early will limit the audience for your > tool... Metacello is cross-platform. Also, Pharo 1.4 doesn't have spec, does > it? Won't spec mean that Versionner can only be used in Pharo 2.0, which is > months away? > > Cheers, > Sean > > -- > View this message in context: http://forum.world.st/Versionner-a-GUI-for-metacello-tp4607220p4634167.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

June 10, 2012

Re: [Pharo-users] Versionner a GUI for metacello

by Sean P. DeNigris

Juan Pablo Sandoval wrote > > As Stef wrote, I am working in a Spec version of Versionner :) I'm wondering whether using spec this early will limit the audience for your tool... Metacello is cross-platform. Also, Pharo 1.4 doesn't have spec, does it? Won't spec mean that Versionner can only be used in Pharo 2.0, which is months away? Cheers, Sean -- View this message in context: http://forum.world.st/Versionner-a-GUI-for-metacello-tp4607220p4634167.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 10, 2012

Re: [Pharo-users] 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

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-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

Re: [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

Re: [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-loading-order-for-seaside-DBXTalk-Magritte-Pharo-1… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

June 9, 2012

Re: [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

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

by Mariano Martinez Peck

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 > 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