Smalltalk › Frameworks & Tools › DBXTalk

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Mariano Martinez Peck

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

On Sat, Jun 9, 2012 at 9:58 PM, Cameron Sanders <[hidden email]> wrote:

On Sat, Jun 9, 2012 at 3:39 PM, Cameron Sanders <[hidden email]> 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
<a href="tel:603-412-2134" value="+16034122134" target="_blank">603-412-2134
PS: any pharo smalltalkers right here in New Hampshire, USA?

--
Mariano
http://marianopeck.wordpress.com

Guillermo Polito

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

On Sat, Jun 9, 2012 at 11:05 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Sat, Jun 9, 2012 at 9:58 PM, Cameron Sanders <[hidden email]> wrote:

On Sat, Jun 9, 2012 at 3:39 PM, Cameron Sanders <[hidden email]> 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=y49B2OsTLCs73vFK&_n&6

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
<a href="tel:603-412-2134" value="+16034122134" target="_blank">603-412-2134
PS: any pharo smalltalkers right here in New Hampshire, USA?

--
Mariano
http://marianopeck.wordpress.com

Sean P. DeNigris

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

Administrator

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

Cheers,
Sean

Cameron Sanders

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

In reply to this post by Guillermo Polito

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

Cameron Sanders

DBXTalk code changes / band-aides

In reply to this post by Mariano Martinez Peck

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

Cameron Sanders

Re: DBXTalk code changes / band-aides

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

Cameron Sanders

DBXTalk & seaside / success in Pier one-click / my 1.4 woes follow-up

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'