Re: [Pharo-project] [Pharo-users] loading order for seaside / DBXTalk + Magritte / Pharo 1.4 / configuration
On Sat, Jun 9, 2012 at 9:58 PM, Cameron Sanders <camsanders@aol.com> wrote:
On Sat, Jun 9, 2012 at 3:39 PM, Cameron Sanders < csanders@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
On Sat, Jun 9, 2012 at 11:05 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Sat, Jun 9, 2012 at 9:58 PM, Cameron Sanders <camsanders@aol.com>wrote:
On Sat, Jun 9, 2012 at 3:39 PM, Cameron Sanders < csanders@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=y49B2OsTLCs...
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
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-Magri... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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
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
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
In my quest to get more than one tool working in one image, I built another image. This time I started with a Pier download (today, June 10, 2012) one-click image, and simply attempted load the DBXTalk. Reading straight from the DBXTalk Documentation page (http://dbxtalk.smallworks.com.ar/Documentation). See below. The Pier-based image did not mask the problems I was having in the Pharo1.4 w/Zinc based image, and so I was able to debug the problems related to #asComponent, so that #asComponent works on DBXTalk built classes. Hence the changes to DBXTalk of the former post. However, when the changes are put into my Pharo1.4/zinc/DBXTalk/seaside image, still, nothing is rendered for the "... asComponent addValidatedForm" -- at least I can move forward with my interfaces by using the Pier image. Unfortunately, Fuel does not work in this Pier based image, so I still have the situation where different images allow me to do different combinations, but not one that allows me to operate my application completely. (Maybe if i put my head in the sand the problems will go away... ?) -Cam - The loading script for DBXTalk - Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOpenDBXDriver'; load. (((Smalltalk at: #ConfigurationOfOpenDBXDriver) perform: #project) perform: #version: with: #stable) load. Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfGlorpDBX'; load. (((Smalltalk at: #ConfigurationOfGlorpDBX) perform: #project) perform: #version: with: #stable) load. "If you want to use the PostgreSQL smalltalk native driver, you can execute instead:" "(((Smalltalk at: #ConfigurationOfGlorpDBX) perform: #project) perform: #version: with: #stable) load: 'GlorpPostgresV2Native'." Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfDBXTools'; load. (((Smalltalk at: #ConfigurationOfDBXTools) perform: #project) perform: #version: with: #stable) load: 'Phoseydon'. "BUT... this err'd so then I manually pulled in most of the DBXTalk packages via monticello. " Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfDBXTools'; load. (((Smalltalk at: #ConfigurationOfDBXTools) perform: #project) perform: #version: with: #stable) load: 'Neptuno'
On 10/06/12 6:16 PM, Cam S wrote:
Unfortunately, Fuel does not work in this Pier based image, so I still have the situation where different images allow me to do different combinations, but not one that allows me to operate my application completely. (Maybe if i put my head in the sand the problems will go away... ?)
I've never had a problem with Fuel in a Pier image. What problem are you having? (It helps if you are specific in your post; otherwise, people have to ask.) What Pier one-click image did you use (link please)? Was it Magritte2 or Magritte3? How did you load Fuel? Did you use ConfigurationOf? Did you specify #stable or #bleedingEdge?
Yanni, I did not know that my post to http://groups.google.com/group/dbxtalk would end up on the pharo lists. Also, this was a side-note to other points about DBXTalk... or I would have given more information about this one aspect. But I am thrilled that Fuel works for you, so I would love to learn more about what works. My Pier download was what was available on Saturday at http://www.piercms.com/download. Then as I noted in that post, I pulled in DBXTalk according to specs on http://dbxtalk.smallworks.com.ar/Download/. I ran through some many variations on image builds in recent days it is a blur. I believe I used the default Magritte in the Pier image -- Magritte2 is the only one I see in the repository (with magritte in the name). *What version Magritte should I be using?* As an aside, in a 1.4 build, I pulled in Magritte3 via the following, and that fixed some name conflicts. Is this the proper way to load it to work with seaside? 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. Then Fuel was loaded using the specs on http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/I... . I did the "Basic Demo": - Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') load. And the "Basic Demo" from the above mentioned page was tried and failed. Actually... wait, the debugger ... -- actually, I do not have time to replicate it right now. But the above scripts, running Pier on a Mac failed. I forget why.
I've never had a problem with Fuel in a Pier image. What problem are you having? (It helps if you are specific in your post; otherwise, people have to ask.)
That is Great News! You imply that it always works, so I will try again. It works fine in a Pharo1.4 image I am working with.
What Pier one-click image did you use (link please)? Was it Magritte2 or Magritte3?
How did you load Fuel? Did you use ConfigurationOf? Did you specify #stable or #bleedingEdge
Thanks for any insight you can offer in advance. Cheers, Cam
On 11/06/12 7:39 PM, Cameron Sanders wrote:
My Pier download was what was available on Saturday at http://www.piercms.com/download.
I thought you were referring to a build from: http://jenkins.lukas-renggli.ch/view/Seaside%203.0/ On that site is a Pier3/Margritte3/Seaside-3.1 build as well. However, AFAICT, all the builds are based on Pharo-1.3, which may be an issue for you. I build my image from Pharo-1.4, adding Seaside-3.0, Magritte2, Pier2.
Then as I noted in that post, I pulled in DBXTalk according to specs on http://dbxtalk.smallworks.com.ar/Download/.
I've used an earlier Glorp port, without problem, but don't use Glorp anymore. I've never used the latest DBXTalk. The Phoseydon scaffolding seems interesting, but you might want to ask the authors what their opinion is on its readiness (the last I remember, from a year or two ago, is was a first release). Note that Magritte3 was done earlier this year, so you may have some issues there.
*What version Magritte should I be using?*
The one that works for you :). Seriously though, Pier seems to be okay with either Magritte version, so whichever one Phoseydon needs will settle it - IIUC, Phoseydon uses Magritte, but I'm too lazy to check at the moment.
As an aside, in a 1.4 build, I pulled in Magritte3 via the following, and that fixed some name conflicts.
What name conflicts did you have? What tools had the conflicts? One of the key "fixes" of Magritte3 was to eliminate overloading of the #description method.
Is this the proper way to load it to work with seaside?
That's the way I would load it (but I'd leave off the Morphic stuff).
((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') load.
I use version 1.7, but because I don't want the other packages in the image, I only load: FuelTests-MartinDias.157.mcz Fuel-MartinDias.479.mcz I've not tried the 1.8 version yet. If you're having trouble with Fuel, you might want to load and run the tests.
Thanks for any insight you can offer in advance.
Whenever I add a new framework, I start from my base image which has all the frameworks that I currently use. Then I load and run the tests for the new framework I want to use. If there are problems, I then start from a basic Pharo image (plus any pre-req packages for the new framework). You should not have to do this, unless you are using frameworks that are relatively new, or you're using a newer Pharo image.
Yanni, Thanks!
On that site is a Pier3/Margritte3/Seaside-3.1 build as well.
Oh, maybe I will try that as a starting point. Thanks!
However, AFAICT, all the builds are based on Pharo-1.3, which may be an issue for you.
I want to use Seaside, Magritte, Fuel (as a back-up storage facility, though primary right now), and Glorp via DBXTalk for relational DB I/O. That's my goal. Perhaps you are right and I am too early at adopting DBXTalk. It looks like it should simplify some of the DB storage.
I build my image from Pharo-1.4, adding Seaside-3.0, Magritte2, Pier2.
I do not need Pier per se. Rather, I simply had no images where the basic Magritte tutorials worked. None of them worked properly right out of the box. But you are saying that Magritte2 in Pharo-1.4, with Seaside 3.0 works together... ... ... so I will try it again. Do you need 1.4, and why? -- if you do not mind sharing. - Let me say: because these configuration problems can be such a pain, especially when one is not aware of the nuances of various packages one might want to adopt, I only recently abandoned my Pharo-1.2 one-click derived image when I had troubles connecting to a DB. I figured it was time to do a complete upgrade. But it has turned into a nightmare, and my project has hit a standstill, ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8')
load.
I use version 1.7, but because I don't want the other packages in the image, I only load:
FuelTests-MartinDias.157.mcz Fuel-MartinDias.479.mcz
Thank you!
I've not tried the 1.8 version yet. If you're having trouble with Fuel, you might want to load and run the tests.
In 1.4 Fuel worked "out of the box", but in the Pier based image, it did not.
Thanks for any insight you can offer in advance.
Whenever I add a new framework, I start from my base image which has all the frameworks that I currently use. Then I load and run the tests for the new framework I want to use. If there are problems....
Pending your answers to my query about why you chose 1.4 over 1.3, I will start fresh again. Cheers & Thanks, Cam
On 11/06/12 10:35 PM, Cameron Sanders wrote:
Do you need 1.4, and why? -- if you do not mind sharing.
I was building on 1.3, and had a second automated build which tracked 1.4. Periodically, I would manually update the 1.4 base image of the build to the then latest 1.4. Each of the builds would load the framework packages I needed, then load my code base. This way I could see problems with the frameworks or my code, as 1.4 progressed. At some point 1.4 was stable enough that I switched over (about 6 months ago).
... I only recently abandoned my Pharo-1.2 one-click derived image when I had troubles connecting to a DB. I figured it was time to do a complete upgrade. But it has turned into a nightmare, and my project has hit a standstill,
Yep, you don't want to be caught by surprise, when upgrading.
Pending your answers to my query about why you chose 1.4 over 1.3, I will start fresh again.
In your situation, I would choose 1.4, because Seaside, Magritte2/3, DBXTalk should work on 1.4 or will be fixed to work on 1.4 - which may not hold true (i.e. the fixing) for 1.3. AFAIK, unless you're heavily attached to Omnibrowser, then there is no reason to use 1.3.
Great, Thanks for the feedback! Good points. I appreciate it. Ciao, Cam On Mon, Jun 11, 2012 at 11:27 PM, Yanni Chiu <yanni@rogers.com> wrote:
On 11/06/12 10:35 PM, Cameron Sanders wrote:
Do you need 1.4, and why? -- if you do not mind sharing.
I was building on 1.3, and had a second automated build which tracked 1.4. Periodically, I would manually update the 1.4 base image of the build to the then latest 1.4. Each of the builds would load the framework packages I needed, then load my code base.
This way I could see problems with the frameworks or my code, as 1.4 progressed. At some point 1.4 was stable enough that I switched over (about 6 months ago).
... I only recently abandoned my Pharo-1.2 one-click derived image
when I had troubles connecting to a DB. I figured it was time to do a complete upgrade. But it has turned into a nightmare, and my project has hit a standstill,
Yep, you don't want to be caught by surprise, when upgrading.
Pending your answers to my query about why you chose 1.4 over 1.3, I
will start fresh again.
In your situation, I would choose 1.4, because Seaside, Magritte2/3, DBXTalk should work on 1.4 or will be fixed to work on 1.4 - which may not hold true (i.e. the fixing) for 1.3. AFAIK, unless you're heavily attached to Omnibrowser, then there is no reason to use 1.3.
OB loads fine in 1.4 too, so... you don't need to use 1.3 even if you are attached to it :) On Jun 12, 2012, at 5:27 AM, Yanni Chiu wrote:
On 11/06/12 10:35 PM, Cameron Sanders wrote:
Do you need 1.4, and why? -- if you do not mind sharing.
I was building on 1.3, and had a second automated build which tracked 1.4. Periodically, I would manually update the 1.4 base image of the build to the then latest 1.4. Each of the builds would load the framework packages I needed, then load my code base.
This way I could see problems with the frameworks or my code, as 1.4 progressed. At some point 1.4 was stable enough that I switched over (about 6 months ago).
... I only recently abandoned my Pharo-1.2 one-click derived image when I had troubles connecting to a DB. I figured it was time to do a complete upgrade. But it has turned into a nightmare, and my project has hit a standstill,
Yep, you don't want to be caught by surprise, when upgrading.
Pending your answers to my query about why you chose 1.4 over 1.3, I will start fresh again.
In your situation, I would choose 1.4, because Seaside, Magritte2/3, DBXTalk should work on 1.4 or will be fixed to work on 1.4 - which may not hold true (i.e. the fixing) for 1.3. AFAIK, unless you're heavily attached to Omnibrowser, then there is no reason to use 1.3.
Yanni, I tried to be clever and start with 1.4 and load Pier3. But the seaside load looks incomplete -- conrol panel and other things missing. (And I have lost another day of muddling with variations.) Rather than debug this build, perhaps you would tell me your base image build process and I will attempt to replicate that. (Please. ;) So you start with 1.4, and then add ... Seaside, Magritte, Pier, and Fuel? In that order? And which versions, please? Thanks in advance, Cam
Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPier3AddOns'; load. ConfigurationOfPier3AddOns load. Should load Seaside, Magritte 3, Pier 3, Pier addons, Pier Admin etc on top of Pharo 1.3 and Pharo 1.4 On 12 June 2012 21:44, Cameron Sanders <camsanders@aol.com> wrote:
Yanni,
I tried to be clever and start with 1.4 and load Pier3. But the seaside load looks incomplete -- conrol panel and other things missing. (And I have lost another day of muddling with variations.) Rather than debug this build, perhaps you would tell me your base image build process and I will attempt to replicate that. (Please. ;)
So you start with 1.4, and then add ... Seaside, Magritte, Pier, and Fuel? In that order? And which versions, please?
Thanks in advance, Cam
Thanks Nick. I wonder --and I will see soon enough-- whether AddOns includes patchwork for ImageSegment as used by #snapshot. That was one problem with the straight up install of Pier 3. Thanks again! Ciao, Cam On Tue, Jun 12, 2012 at 5:09 PM, Nick Ager <nick.ager@gmail.com> wrote:
Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPier3AddOns'; load.
ConfigurationOfPier3AddOns load.
Should load Seaside, Magritte 3, Pier 3, Pier addons, Pier Admin etc on top of Pharo 1.3 and Pharo 1.4
Nick & Yanni, Starting with a clean Pharo 1.4-one-click, running on a Mac, and loading as listed below (see botton of page), does not deliver the desired results. A trivial Magritte described object, rendered (via #call:) "...asComponent addValidatedForm; yourself)" displays only the buttons, and no content editors. It silently fails. My test is the most trivial test of the Person tutorial for Magritte, grab my partial version from MCHttpRepository location: 'http://www.debrispublishing.com/camshared' user: '' password: '' and package is 'Cam'. See the class method of the Manager to register the app; then open a browser on localhost:8080/cam and when one adds a person, there is nothing but buttons. Perhaps the pattern of use is deprecated? CamPersonManager>>add | p | p := self call: (CamPerson new asComponent addValidatedForm ; yourself). p ifNotNil: [ self persons add: p] This same trivial sample code does work in one Pier image I was using. But I was trying really hard to move to a 1.4 image, for the numerous small improvements and fixes; and as Yanni suggested, to be positioned for future support. *If anyone has seaside/Magritte working in 1.4 would you please share with me your exact loading scripts (in proper sequence), or a snapshot of the minimal image (without any extras, of course)?* In the meantime I will try a 1.3 build ... again. I have put a lot of hours in trying to get a 1.4 build that works -- and a few failed 1.3 builds. Everyone else seems to do this in stride. But apparently, I am doing something wrong... dumb... idiotic... and my co-workers are starting to doubt me & my choice of platforms. Any help is most appreciated. Thanks in advance, Cam PS: what I loaded and how -- using Pier config to get seaside & magritte combos that work together (with regard to #description, etc.). Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPier3'; load. (Smalltalk at: #ConfigurationOfPier3) load. Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPier3AddOns'; load. (Smalltalk at: #ConfigurationOfPier3AddOns) load. "Error about ImageSegment not being available -- used by #serialize: which is used by #snapshot -- but not an issue for me right now, so Proceed" Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') load.
On 12/06/12 7:52 PM, Cameron Sanders wrote:
My test is the most trivial test of the Person tutorial for Magritte, grab my partial version from MCHttpRepository location: 'http://www.debrispublishing.com/camshared' user: '' password: ''
and package is 'Cam'.
Your code worked in my Magritte2 image. But, it looks like you built yourself a Magritte3 image. If so, you must "port" your example from Magritte2 to Magritte3. I'm not sure where the doc's are, but web search turned up: http://www.slideshare.net/nickager/magritte3 You need to change the #descriptionXXX stuff to use pragmas, if I remember correctly. Again, I've not ported my code to Magritte3, but I had a brief look earlier to understand what issues I would have.
and have a look at this video: https://vimeo.com/37032840 On 13 June 2012 04:16, Yanni Chiu <yanni@rogers.com> wrote:
On 12/06/12 7:52 PM, Cameron Sanders wrote:
My test is the most trivial test of the Person tutorial for Magritte, grab my partial version from MCHttpRepository location: 'http://www.debrispublishing.**com/camshared<http://www.debrispublishing.com/camshared> ' user: '' password: ''
and package is 'Cam'.
Your code worked in my Magritte2 image. But, it looks like you built yourself a Magritte3 image. If so, you must "port" your example from Magritte2 to Magritte3. I'm not sure where the doc's are, but web search turned up: http://www.slideshare.net/**nickager/magritte3<http://www.slideshare.net/nickager/magritte3>
You need to change the #descriptionXXX stuff to use pragmas, if I remember correctly. Again, I've not ported my code to Magritte3, but I had a brief look earlier to understand what issues I would have.
Let us know how we can help you. Stef On Jun 13, 2012, at 1:52 AM, Cameron Sanders wrote:
Nick & Yanni,
Starting with a clean Pharo 1.4-one-click, running on a Mac, and loading as listed below (see botton of page), does not deliver the desired results. A trivial Magritte described object, rendered (via #call:) "...asComponent addValidatedForm; yourself)" displays only the buttons, and no content editors. It silently fails.
My test is the most trivial test of the Person tutorial for Magritte, grab my partial version from MCHttpRepository location: 'http://www.debrispublishing.com/camshared' user: '' password: ''
and package is 'Cam'. See the class method of the Manager to register the app; then open a browser on localhost:8080/cam and when one adds a person, there is nothing but buttons.
Perhaps the pattern of use is deprecated? CamPersonManager>>add | p | p := self call: (CamPerson new asComponent addValidatedForm ; yourself). p ifNotNil: [ self persons add: p]
This same trivial sample code does work in one Pier image I was using. But I was trying really hard to move to a 1.4 image, for the numerous small improvements and fixes; and as Yanni suggested, to be positioned for future support.
If anyone has seaside/Magritte working in 1.4 would you please share with me your exact loading scripts (in proper sequence), or a snapshot of the minimal image (without any extras, of course)? In the meantime I will try a 1.3 build ... again.
I have put a lot of hours in trying to get a 1.4 build that works -- and a few failed 1.3 builds. Everyone else seems to do this in stride. But apparently, I am doing something wrong... dumb... idiotic... and my co-workers are starting to doubt me & my choice of platforms. Any help is most appreciated.
Thanks in advance, Cam PS: what I loaded and how -- using Pier config to get seaside & magritte combos that work together (with regard to #description, etc.).
Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPier3'; load. (Smalltalk at: #ConfigurationOfPier3) load.
Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPier3AddOns'; load.
(Smalltalk at: #ConfigurationOfPier3AddOns) load.
"Error about ImageSegment not being available -- used by #serialize: which is used by #snapshot -- but not an issue for me right now, so Proceed"
Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFuel'; load. ((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') load.
((Smalltalk at: #ConfigurationOfFuel) project version: '1.8')
load.
I use version 1.7, but because I don't want the other packages in the image,
what do you mean with that phrase? -- Mariano http://marianopeck.wordpress.com
On 12/06/12 3:46 AM, Mariano Martinez Peck wrote:
((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') load.
I use version 1.7, but because I don't want the other packages in the image,
what do you mean with that phrase?
It's badly worded. Here's another attempt... I use version 1.7, but I don't load it using ConfigurationOfFuel, because I don't want the other packages (such as benchmarks, SIXX, etc.). So, I load just the packages: ...
On Tue, Jun 12, 2012 at 10:28 PM, Yanni Chiu <yanni@rogers.com> wrote:
On 12/06/12 3:46 AM, Mariano Martinez Peck wrote:
((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') load.
I use version 1.7, but because I don't want the other packages in the image,
what do you mean with that phrase?
It's badly worded. Here's another attempt...
I use version 1.7, but I don't load it using ConfigurationOfFuel, because I don't want the other packages (such as benchmarks, SIXX, etc.). So, I load just the packages: ...
In we DO NOT load SIXX, or other serializers (but yes our Benchmark package, progressUpate and examples) ((Smalltalk at: #ConfigurationOfFuel) project version: '1.7') record -> a MetacelloNullRecordingMCSpecLoader(linear load : linear load : 1.7 [ConfigurationOfFuel] load : Fuel-MartinDias.479 load : FuelTests-MartinDias.157 load : FuelProgressUpdate-MartinDias.27 load : FuelBenchmarks-MartinDias.88 load : FuelExamples-MartinDias.5) Now, in Version 1.8 by default we only install the core and the tests of the core: (Smalltalk at: #ConfigurationOfFuel) project stableVersion record -> a MetacelloNullRecordingMCSpecLoader(linear load : linear load : 1.8 [ConfigurationOfFuel] load : Fuel-MartinDias.685 load : FuelTests-MartinDias.267 load : FuelCompatibilityBeforePharo20-MartinDias.4) -- Mariano http://marianopeck.wordpress.com
On 12/06/12 4:36 PM, Mariano Martinez Peck wrote:
In we DO NOT load SIXX, or other serializers (but yes our Benchmark package, progressUpate and examples)
Maybe it was versions prior to 1.7 that included SIXX, but the 1 or 2 times I tried to use the ConfigurationOf it was pulling in a lot more than I wanted. Since there was only a single monticello package for the core (and one for the tests), I've been loading just that one package since then.
Then Fuel was loaded using the specs on http://rmod.lille.inria.fr/web/pier/software/Fuel/Version1.8/Documentation/I... . I did the "Basic Demo": -
Gofer it
squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfFuel'; load.
((Smalltalk at: #ConfigurationOfFuel) project version: '1.8') load.
And the "Basic Demo" from the above mentioned page was tried and failed. Actually... wait, the debugger ... -- actually, I do not have time to replicate it right now. But the above scripts, running Pier on a Mac failed. I forget why.
Yes, it fails because of a small detail. Nothing important, believe me. Run tests and you should have all 248 tests in green. Cheers, -- Mariano http://marianopeck.wordpress.com
participants (9)
-
Cam S -
Cameron Sanders
-
Esteban Lorenzano -
Guillermo Polito -
Mariano Martinez Peck -
Nick Ager -
Sean P. DeNigris -
Stéphane Ducasse -
Yanni Chiu