[Pharo-project] ORM for Pharo
My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I have tables for most of it. What are the choices I have for doing ORM in Pharo? ¿Does GLORP work? ¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express. Best regards, Esteban A. Maringolo
On Fri, Aug 14, 2009 at 6:14 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I have tables for most of it.
What are the choices I have for doing ORM in Pharo?
¿Does GLORP work? ¿Any other options?
Yes. Glorp does work and with the 100% (850) of the tests green. I am who did the port from Squeak to Pharo. I created a GlorpPharoLoader but unfortunately it doesn't work right now because some packages were added that cause problems ( I am waiting the admin remove them). However, there are 2 things to take into consideration: 1) The Squeak/Pharo port of Glorp is VERY olde (years old). Diógenes Moreira is doing a new port but it is yet in process. 2) Glorp, as it is now, in Squeak/Pharo only works for the PostgreSQL native driver. However, ESUG (http://www.esug.org/Promotion/SummerTalk) soponsor us (SqueakDBX team) again this year to do an SqueakDBX / Glorp integration. This has 2 parts: 1) Refactor Glorp so that the SqueakDatabaseAccessor has nothing hardcoded to a particular driver but to a unified API. Then, you can implement the drivers you want. We already did this refactor and we also did the native postgresql driver (with the stuff we removed from SqueakDatabaseAccesor) and an SqueakDBX driver (that only works for PostgreSQL right now). This step is almost finished. 2) Complete the SqueakDBX Glorp driver so that it can used for all backends. We are now focusing in Oracle and MySQL. And also with the new port of Diogenes. Of course there are others options: - Magritte-RDB - SqueakSave: very very interesting project. See: http://www.hpi.uni-potsdam.de/hirschfeld/projects/sqsave/index.html - Moe Best, Mariano
I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express.
Best regards,
Esteban A. Maringolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
SqueakSave seems to bee pretty attractive, does it work in Pharo? Shouldn't it be PharoSave? :) Regards! Esteban A. Maringolo
On Tue, Aug 18, 2009 at 10:55 AM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
SqueakSave seems to bee pretty attractive, does it work in Pharo?
hehehehe I did the same question to him. Actually, I have been sending several private emails with hie because as SqueakSave works for PostgreSQL and MySQL native drivers he had to do a lot of effort. Now, he thought to replace all that stuff with SqueakDBX. Regarding to your question, he told me he didn't tested yet, but wanted to do it before ESUG (he also goes there). But we can ask him again if it was tested. However, take into account this project is still in development, not productive. But sound REALLY interesting. They have a lot of people using it there. It seems to be a very good solution for small/medium app where I don't want to spend time doing mappings, something like active record ?
Shouldn't it be PharoSave? :)
I am sorry I am not agree. I, as a software developer, would like that my project works not only in Pharo but also in all of its forks. SqueakDBX runs in Squeak, Pharo and (I didn't test it) but should work in Cuis (and if not, let me know please) or whatever other squeak fork. I put the name of the abstract class ;) Cheers, Mariano
Regards!
Esteban A. Maringolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/14 <csrabak@bol.com.br>
Esteban,
I'm comenting this on *philosophical* grounds.
I understand the efforts to have SqueakDBX and other ORM in Pharo are motivated by Seaside and other "production" initiatives so, again, my food for thought is more an intellectual contribution which I see as useful for Pharo as project:
I don't see Pharo *any time soon*® having all the toolset to be able to compete in the CRUD¹ realm with more streamlined tools and besides, not matter how much theoretical work has been done on ORM, the "impedance mismatch" is still there,
Hi! I am agree with you about the "impedance mismatch". I think that if I am free to choose a persistence strategy I would use an OODB. However, if we are talking about real enterprise application (not a simple webpage) being able to choose the persistence strategy is practically impossible. We did a survey last year and the results were that most of the times you cannot choose. Of course, the client has a lot of reasons: - The client already has a RDBMS - They had paid for it and have the license (sometimes) - They want a company's support. The only company here is Gemstone. - RDBMS has history and it is an standard - They have knowledge about it - Interaction with other system (even legazy systems) - They are afraid of using another persistence strategy - They want to use SQL - They have DBAs - The persistence is difficult to negotiate So. In my opinion, if Pharo wants to be used really as a platform for enterprise applications (competing to java, .NET, etc), it must have a good relational solution. Of course, when you are able to choose, you can go for another approach like OODB. Best, Mariano
a recent and practicall account of this (for Squeak) can be found in
http://onsmalltalk.com/simple-image-based-persistence-in-squeak
also, AIDA/Web has been able to run only storing thing in the image! See
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba...
Since we'll increase the educational efforts to spread Pharo, I think that as technology we should to recover a bit of Smalltalk technology and be first more Object Oriented and then see if ORM still is so needed.
my 0.0199999....
--
Cesar Rabak
[1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete Em 14/08/2009 16:14, *Esteban A. Maringolo < emaringolo@gmail.com >*escreveu:
My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I have tables for most of it.
What are the choices I have for doing ORM in Pharo?
¿Does GLORP work? ¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express.
Best regards,
Esteban A. Maringolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/14 <csrabak@bol.com.br>
Mariano,
I agree (and I myself have been on the Research side getting answers similar to those ones) in fact I'll add another item to your list:
-- They have an "architectural steering committee" that dictates use of some RDBS
I've seen this even requiring some ERP used different database engine thas suggested by supplier. . .
So if we want to compete with enterprise applications we need to get into some Enterprise:
We're still thinkering with printing in Pharo (and this is PITA when attempting to be platform agnostic), so no Report Generator still, no matter how well you connect to a RDBS, any slightly above trivial example CRUD application will need this support.
Our present set of widgets is sleek but still not as comprehensive as the other competing approaches, and we still have not created enough baseline to have an "echo system" so third parties can augment them as it happens now with Java, .Net and happened (and still as legacy updates) in Delphi and VB.
So if the goal is to reach those enterprise trench we have to find some company that would profit of having [Pharo] Smalltalk as a *primary*language to customize or augment their system, as today (say as sake of example, SAP has ABAP but with Netweaver is going Java, and they competitors similar path).
Let's think about this: historically some (comercial) Smalltalks allowed via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things similar as VB (in fact even Tcl and Python allow that), but what is the "productivity" of programmer that finds a tutorial or an example in VB and has to "translate" it to Smalltalk?
As today can we enumerate what would be an advantage of doing something in Pharo instead of some "mainstream" language just to do some GUI painting CRUD application?
I don't know if I understand you. The idea and goal behind Pharo is to have the open, free, clean and robust smalltalk that we were missing for years for commercial applications. At least that's my idea of Pharo. It must be a platform and a base where you can create tools in it and with both of them create real applications. In my opinion Pharo shouldn't be associated with a particular UI (web or desktop) neither to a persistence strategy. Pharo must be the base of all that. So then you can have differents alternatives: For UI's you can have PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But pharo is not coupled with any of them. You will then choose the solutions that best feets your needs. In summary, I would love to use Pharo as platform to build enterprise and commercial applications. No matter how do I persist or display my objects. Best, Mariano
again my 0.01999....
Regards,
--
Cesar Rabak
Em 14/08/2009 16:57, *Mariano Martinez Peck < marianopeck@gmail.com >*escreveu:
2009/8/14 <csrabak@bol.com.br<http://mce_host/compose?to=csrabak@bol.com.br>
Esteban,
I'm comenting this on *philosophical* grounds.
I understand the efforts to have SqueakDBX and other ORM in Pharo are motivated by Seaside and other "production" initiatives so, again, my food for thought is more an intellectual contribution which I see as useful for Pharo as project:
I don't see Pharo *any time soon*® having all the toolset to be able to compete in the CRUD¹ realm with more streamlined tools and besides, not matter how much theoretical work has been done on ORM, the "impedance mismatch" is still there,
Hi! I am agree with you about the "impedance mismatch". I think that if I am free to choose a persistence strategy I would use an OODB. However, if we are talking about real enterprise application (not a simple webpage) being able to choose the persistence strategy is practically impossible. We did a survey last year and the results were that most of the times you cannot choose. Of course, the client has a lot of reasons:
- The client already has a RDBMS - They had paid for it and have the license (sometimes) - They want a company's support. The only company here is Gemstone. - RDBMS has history and it is an standard - They have knowledge about it - Interaction with other system (even legazy systems) - They are afraid of using another persistence strategy - They want to use SQL - They have DBAs - The persistence is difficult to negotiate
So. In my opinion, if Pharo wants to be used really as a platform for enterprise applications (competing to java, .NET, etc), it must have a good relational solution. Of course, when you are able to choose, you can go for another approach like OODB.
Best,
Mariano
a recent and practicall account of this (for Squeak) can be found in
http://onsmalltalk.com/simple-image-based-persistence-in-squeak
also, AIDA/Web has been able to run only storing thing in the image! See
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba...
Since we'll increase the educational efforts to spread Pharo, I think that as technology we should to recover a bit of Smalltalk technology and be first more Object Oriented and then see if ORM still is so needed.
my 0.0199999....
--
Cesar Rabak
[1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete Em 14/08/2009 16:14, *Esteban A. Maringolo < emaringolo@gmail.com<http://mce_host/compose?to=emaringolo@gmail.com>> * escreveu:
My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I have tables for most of it.
What are the choices I have for doing ORM in Pharo?
¿Does GLORP work? ¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express.
Best regards,
Esteban A. Maringolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<http://../../../undefined/compose?to=Pharo> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<http://../../../undefined/compose?to=Pharo> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/8/15 <csrabak@bol.com.br>
Mariano,
I can understand the goal be Pharo idea and goal as you post. What I'm trying to bring (and hopefully *add* to this discussion) is how can we arrive there.
We need to narrow down the definition of "enterprise application" and see where Pharo can start to thrive. No all encompassing approach would work as notwithstanding how poweful and complete Pharo *could *become it will not be *anytime soon.*
The notion that Pharo be not assotiated *per se* to any UI it is a strong (and I vote to maintain it) design goal but in order to push forward Pharo together with robust and clean implementation we'll need a lot of energy and effort to produce enough educational materials like tutorial, manuals, etc., it will be confusing all the time have an example that do not work in another minor variation of UI (to stay in a single topic).
So I return to the point: we need to have more clear goals on what particular realm we see Pharo as feasible for enterprise development and be able to enumerate what are the advantages of Pharo versus the other approaches.
I am totally agree. Would like to hear the board opinion. Hope it is more explicit now ;-)
Yes it was ;)
Em 14/08/2009 20:42, *Mariano Martinez Peck < marianopeck@gmail.com >*escreveu:
2009/8/14 <csrabak@bol.com.br<http://mce_host/compose?to=csrabak@bol.com.br>
Mariano,
I agree (and I myself have been on the Research side getting answers similar to those ones) in fact I'll add another item to your list:
-- They have an "architectural steering committee" that dictates use of some RDBS
I've seen this even requiring some ERP used different database engine thas suggested by supplier. . .
So if we want to compete with enterprise applications we need to get into some Enterprise:
We're still thinkering with printing in Pharo (and this is PITA when attempting to be platform agnostic), so no Report Generator still, no matter how well you connect to a RDBS, any slightly above trivial example CRUD application will need this support.
Our present set of widgets is sleek but still not as comprehensive as the other competing approaches, and we still have not created enough baseline to have an "echo system" so third parties can augment them as it happens now with Java, .Net and happened (and still as legacy updates) in Delphi and VB.
So if the goal is to reach those enterprise trench we have to find some company that would profit of having [Pharo] Smalltalk as a *primary*language to customize or augment their system, as today (say as sake of example, SAP has ABAP but with Netweaver is going Java, and they competitors similar path).
Let's think about this: historically some (comercial) Smalltalks allowed via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things similar as VB (in fact even Tcl and Python allow that), but what is the "productivity" of programmer that finds a tutorial or an example in VB and has to "translate" it to Smalltalk?
As today can we enumerate what would be an advantage of doing something in Pharo instead of some "mainstream" language just to do some GUI painting CRUD application?
I don't know if I understand you. The idea and goal behind Pharo is to have the open, free, clean and robust smalltalk that we were missing for years for commercial applications. At least that's my idea of Pharo. It must be a platform and a base where you can create tools in it and with both of them create real applications.
In my opinion Pharo shouldn't be associated with a particular UI (web or desktop) neither to a persistence strategy. Pharo must be the base of all that. So then you can have differents alternatives: For UI's you can have PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But pharo is not coupled with any of them. You will then choose the solutions that best feets your needs.
In summary, I would love to use Pharo as platform to build enterprise and commercial applications. No matter how do I persist or display my objects.
Best,
Mariano
again my 0.01999....
Regards,
--
Cesar Rabak
Em 14/08/2009 16:57, *Mariano Martinez Peck < marianopeck@gmail.com<http://mce_host/compose?to=marianopeck@gmail.com>> * escreveu:
2009/8/14 <csrabak@bol.com.br<http://mce_host/compose?to=csrabak@bol.com.br>
Esteban,
I'm comenting this on *philosophical* grounds.
I understand the efforts to have SqueakDBX and other ORM in Pharo are motivated by Seaside and other "production" initiatives so, again, my food for thought is more an intellectual contribution which I see as useful for Pharo as project:
I don't see Pharo *any time soon*® having all the toolset to be able to compete in the CRUD¹ realm with more streamlined tools and besides, not matter how much theoretical work has been done on ORM, the "impedance mismatch" is still there,
Hi! I am agree with you about the "impedance mismatch". I think that if I am free to choose a persistence strategy I would use an OODB. However, if we are talking about real enterprise application (not a simple webpage) being able to choose the persistence strategy is practically impossible. We did a survey last year and the results were that most of the times you cannot choose. Of course, the client has a lot of reasons:
- The client already has a RDBMS - They had paid for it and have the license (sometimes) - They want a company's support. The only company here is Gemstone. - RDBMS has history and it is an standard - They have knowledge about it - Interaction with other system (even legazy systems) - They are afraid of using another persistence strategy - They want to use SQL - They have DBAs - The persistence is difficult to negotiate
So. In my opinion, if Pharo wants to be used really as a platform for enterprise applications (competing to java, .NET, etc), it must have a good relational solution. Of course, when you are able to choose, you can go for another approach like OODB.
Best,
Mariano
a recent and practicall account of this (for Squeak) can be found in
http://onsmalltalk.com/simple-image-based-persistence-in-squeak
also, AIDA/Web has been able to run only storing thing in the image! See
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba...
Since we'll increase the educational efforts to spread Pharo, I think that as technology we should to recover a bit of Smalltalk technology and be first more Object Oriented and then see if ORM still is so needed.
my 0.0199999....
--
Cesar Rabak
[1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete Em 14/08/2009 16:14, *Esteban A. Maringolo < emaringolo@gmail.com<http://mce_host/compose?to=emaringolo@gmail.com>> * escreveu:
My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I have tables for most of it.
What are the choices I have for doing ORM in Pharo?
¿Does GLORP work? ¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express.
Best regards,
Esteban A. Maringolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<http://../../../undefined/compose?to=Pharo> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<http://../../../undefined/compose?to=Pharo> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr<http://../../../undefined/compose?to=Pharo> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
IMHO Pharo must stick to the roadmap milestones, keeping clear boundaries on what goes in and out - I value that some people are acting as gatekeepers. Then a second community, those who develop frameworks that run on top of Pharo, like the authors of frameworks of Seaside, Glorp,,SqueakDBX (to name a few coming from the top of my head) may probably try to ensure their frameworks progresses aligned with the Pharo releases, demanding a rrobust and performant Smalltalk system impementattion. Now, to boost Pharo adoption, beyod smalltalkers, and to capture the attention of new people, probably not familiar with the language, technology, style, the system itself, the paradigm, and (why not) the culture,, a new foundation of spin-off should address the level of effort to envision and manufacture... #1 a rich set of widgets and #2 recipes showing how to combine them to produce high-impact realtime client GUIs As an example I mention what - Swing, AWT and SWT is for Java, - Tk is for Tcl, - GTK+ to C++, (and lots of....) - UIPaainter to VisualWorks, and so on..:) -----Mensaje original----- De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de csrabak@bol.com.br Enviado el: Sábado, 15 de Agosto de 2009 01:04 p.m. Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] ORM for Pharo -- ½ OFF Mariano, I can understand the goal be Pharo idea and goal as you post. What I'm trying to bring (and hopefully add to this discussion) is how can we arrive there. We need to narrow down the definition of "enterprise application" and see where Pharo can start to thrive. No all encompassing approach would work as notwithstanding how poweful and complete Pharo could become it will not be anytime soon. The notion that Pharo be not assotiated per se to any UI it is a strong (and I vote to maintain it) design goal but in order to push forward Pharo together with robust and clean implementation we'll need a lot of energy and effort to produce enough educational materials like tutorial, manuals, etc., it will be confusing all the time have an example that do not work in another minor variation of UI (to stay in a single topic). So I return to the point: we need to have more clear goals on what particular realm we see Pharo as feasible for enterprise development and be able to enumerate what are the advantages of Pharo versus the other approaches. Hope it is more explicit now ;-) Em 14/08/2009 20:42, Mariano Martinez Peck < marianopeck@gmail.com > escreveu: 2009/8/14 <csrabak@bol.com.br> Mariano, I agree (and I myself have been on the Research side getting answers similar to those ones) in fact I'll add another item to your list: -- They have an "architectural steering committee" that dictates use of some RDBS I've seen this even requiring some ERP used different database engine thas suggested by supplier. . . So if we want to compete with enterprise applications we need to get into some Enterprise: We're still thinkering with printing in Pharo (and this is PITA when attempting to be platform agnostic), so no Report Generator still, no matter how well you connect to a RDBS, any slightly above trivial example CRUD application will need this support. Our present set of widgets is sleek but still not as comprehensive as the other competing approaches, and we still have not created enough baseline to have an "echo system" so third parties can augment them as it happens now with Java, .Net and happened (and still as legacy updates) in Delphi and VB. So if the goal is to reach those enterprise trench we have to find some company that would profit of having [Pharo] Smalltalk as a primary language to customize or augment their system, as today (say as sake of example, SAP has ABAP but with Netweaver is going Java, and they competitors similar path). Let's think about this: historically some (comercial) Smalltalks allowed via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things similar as VB (in fact even Tcl and Python allow that), but what is the "productivity" of programmer that finds a tutorial or an example in VB and has to "translate" it to Smalltalk? As today can we enumerate what would be an advantage of doing something in Pharo instead of some "mainstream" language just to do some GUI painting CRUD application? I don't know if I understand you. The idea and goal behind Pharo is to have the open, free, clean and robust smalltalk that we were missing for years for commercial applications. At least that's my idea of Pharo. It must be a platform and a base where you can create tools in it and with both of them create real applications. In my opinion Pharo shouldn't be associated with a particular UI (web or desktop) neither to a persistence strategy. Pharo must be the base of all that. So then you can have differents alternatives: For UI's you can have PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But pharo is not coupled with any of them. You will then choose the solutions that best feets your needs. In summary, I would love to use Pharo as platform to build enterprise and commercial applications. No matter how do I persist or display my objects. Best, Mariano again my 0.01999.... Regards, -- Cesar Rabak Em 14/08/2009 16:57, Mariano Martinez Peck < marianopeck@gmail.com > escreveu: 2009/8/14 <csrabak@bol.com.br> Esteban, I'm comenting this on philosophical grounds. I understand the efforts to have SqueakDBX and other ORM in Pharo are motivated by Seaside and other "production" initiatives so, again, my food for thought is more an intellectual contribution which I see as useful for Pharo as project: I don't see Pharo any time soon® having all the toolset to be able to compete in the CRUD¹ realm with more streamlined tools and besides, not matter how much theoretical work has been done on ORM, the "impedance mismatch" is still there, Hi! I am agree with you about the "impedance mismatch". I think that if I am free to choose a persistence strategy I would use an OODB. However, if we are talking about real enterprise application (not a simple webpage) being able to choose the persistence strategy is practically impossible. We did a survey last year and the results were that most of the times you cannot choose. Of course, the client has a lot of reasons: - The client already has a RDBMS - They had paid for it and have the license (sometimes) - They want a company's support. The only company here is Gemstone. - RDBMS has history and it is an standard - They have knowledge about it - Interaction with other system (even legazy systems) - They are afraid of using another persistence strategy - They want to use SQL - They have DBAs - The persistence is difficult to negotiate So. In my opinion, if Pharo wants to be used really as a platform for enterprise applications (competing to java, .NET, etc), it must have a good relational solution. Of course, when you are able to choose, you can go for another approach like OODB. Best, Mariano a recent and practicall account of this (for Squeak) can be found in http://onsmalltalk.com/simple-image-based-persistence-in-squeak also, AIDA/Web has been able to run only storing thing in the image! See http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba... Since we'll increase the educational efforts to spread Pharo, I think that as technology we should to recover a bit of Smalltalk technology and be first more Object Oriented and then see if ORM still is so needed. my 0.0199999.... -- Cesar Rabak [1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete Em 14/08/2009 16:14, Esteban A. Maringolo < emaringolo@gmail.com > escreveu: My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I have tables for most of it. What are the choices I have for doing ORM in Pharo? ¿Does GLORP work? ¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express. Best regards, Esteban A. Maringolo _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I'm arriving late to this discussion... I think that having a good ORM solution is important to enterprise applications... and not only enterprise but if you have tables with LOTS of rows, you need to map them to objects. Don't start talking about Gemstone, I like, it's rock solid, but sometimes, most of the times I would say, it's out of the discussion. Even with objects mapped to tables, you can do real good object programming. I don't want to see another isolated Smalltalk again, the more able you are to interconnect with the external world, the better. Regards, Esteban A. Maringolo 2009/8/16 Carlos Crosetti <carlos@mostar.com.ar>:
IMHO Pharo must stick to the roadmap milestones, keeping clear boundaries on what goes in and out - I value that some people are acting as gatekeepers.
Then a second community, those who develop frameworks that run on top of Pharo, like the authors of frameworks of Seaside, Glorp,,SqueakDBX (to name a few coming from the top of my head) may probably try to ensure their frameworks progresses aligned with the Pharo releases, demanding a rrobust and performant Smalltalk system  impementattion.
Now, to boost Pharo adoption, beyod smalltalkers, and to capture the attention of new people, probably not familiar with the language, technology, style, the system itself, the paradigm, and (why not) the culture,, a new foundation of spin-off should address the level of effort to envision and manufacture... #1 a rich set of widgets and #2 recipes showing how to combine them to produce high-impact realtime client GUIs
As an example I mention what - Swing, AWT and SWT is for Java, - Tk is for Tcl, - GTK+ to C++, (and lots of....) - UIPaainter to VisualWorks,
and so on..:)
-----Mensaje original----- De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de csrabak@bol.com.br Enviado el: Sábado, 15 de Agosto de 2009 01:04 p.m. Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] ORM for Pharo -- ½ OFF
Mariano,
I can understand the goal be Pharo idea and goal as you post. What I'm trying to bring (and hopefully add to this discussion) is how can we arrive there.
We need to narrow down the definition of "enterprise application" and see where Pharo can start to thrive. No all encompassing approach would work as notwithstanding how poweful and complete Pharo could become it will not be anytime soon.
The notion that Pharo be not assotiated per se to any UI it is a strong (and I vote to maintain it) design goal but in order to push forward Pharo together with robust and clean implementation we'll need a lot of energy and effort to produce enough educational materials like tutorial, manuals, etc., it will be confusing all the time have an example that do not work in another minor variation of UI (to stay in a single topic).
So I return to the point: we need to have more clear goals on what particular realm we see Pharo as feasible for enterprise development and be able to enumerate what are the advantages of Pharo versus the other approaches.
Hope it is more explicit now ;-)
Em 14/08/2009 20:42, Mariano Martinez Peck < marianopeck@gmail.com > escreveu:
2009/8/14 <csrabak@bol.com.br>
Mariano,
I agree (and I myself have been on the Research side getting answers similar to those ones) in fact I'll add another item to your list:
-- They have an "architectural steering committee" that dictates use of some RDBS
I've seen this even requiring some ERP used different database engine thas suggested by supplier. . .
So if we want to compete with enterprise applications we need to get into some Enterprise:
We're still thinkering with printing in Pharo (and this is PITA when attempting to be platform agnostic), so no Report Generator still, no matter how well you connect to a RDBS, any slightly above trivial example CRUD application will need this support.
Our present set of widgets is sleek but still not as comprehensive as the other competing approaches, and we still have not created enough baseline to have an "echo system" so third parties can augment them as it happens now with Java, .Net and happened (and still as legacy updates) in Delphi and VB.
So if the goal is to reach those enterprise trench we have to find some company that would profit of having [Pharo] Smalltalk as a primary language to customize or augment their system, as today (say as sake of example, SAP has ABAP but with Netweaver is going Java, and they competitors similar path).
Let's think about this: historically some (comercial) Smalltalks allowed via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things similar as VB (in fact even Tcl and Python allow that), but what is the "productivity" of programmer that finds a tutorial or an example in VB and has to "translate" it to Smalltalk?
As today can we enumerate what would be an advantage of doing something in Pharo instead of some "mainstream" language just to do some GUI painting CRUD application?
I don't know if I understand you. The idea and goal behind Pharo is to have the open, free, clean and robust smalltalk that we were missing for years for commercial applications. At least that's my idea of Pharo. It must be a platform and a base where you can create tools in it and with both of them create real applications.
In my opinion Pharo shouldn't be associated with a particular UI (web or desktop) neither to a persistence strategy. Pharo must be the base of all that. So then you can have differents alternatives: For UI's you can have PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But pharo is not coupled with any of them. You will then choose the solutions that best feets your needs.
In summary, I would love to use Pharo as platform to build enterprise and commercial applications. No matter how do I persist or display my objects.
Best,
Mariano
again my 0.01999....
Regards,
--
Cesar Rabak
Em 14/08/2009 16:57, Mariano Martinez Peck < marianopeck@gmail.com > escreveu:
2009/8/14 <csrabak@bol.com.br>
Esteban,
I'm comenting this on philosophical grounds.
I understand the efforts to have SqueakDBX and other ORM in Pharo are motivated by Seaside and other "production" initiatives so, again, my food for thought is more an intellectual contribution which I see as useful for Pharo as project:
I don't see Pharo any time soon® having all the toolset to be able to compete in the CRUD¹ realm with more streamlined tools and besides, not matter how much theoretical work has been done on ORM, the "impedance mismatch" is still there,
Hi! I am agree with you about the "impedance mismatch". I think that if I am free to choose a persistence strategy I would use an OODB. However, if we are talking about real enterprise application (not a simple webpage) being able to choose the persistence strategy is practically impossible. We did a survey last year and the results were that most of the times you cannot choose. Of course, the client has a lot of reasons:
- The client already has a RDBMS - They had paid for it and have the license (sometimes) - They want a company's support. The only company here is Gemstone. - RDBMS has history and it is an standard - They have knowledge about it - Interaction with other system (even legazy systems) - They are afraid of using another persistence strategy - They want to use SQL - They have DBAs - The persistence is difficult to negotiate
So. In my opinion, if Pharo wants to be used really as a platform for enterprise applications (competing to java, .NET, etc), it must have a good relational solution. Of course, when you are able to choose, you can go for another approach like OODB.
Best,
Mariano
a recent and practicall account of this (for Squeak) can be found in
http://onsmalltalk.com/simple-image-based-persistence-in-squeak
also, AIDA/Web has been able to run only storing thing in the image! See
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba...
Since we'll increase the educational efforts to spread Pharo, I think that as technology we should to recover a bit of Smalltalk technology and be first more Object Oriented and then see if ORM still is so needed.
my 0.0199999....
--
Cesar Rabak
[1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete Em 14/08/2009 16:14, Esteban A. Maringolo < emaringolo@gmail.com > escreveu:
My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I have tables for most of it.
What are the choices I have for doing ORM in Pharo?
¿Does GLORP work? ¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express.
Best regards,
Esteban A. Maringolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Aug 18, 2009 at 10:37 AM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
I'm arriving late to this discussion...
I think that having a good ORM solution is important to enterprise applications... and not only enterprise but if you have tables with LOTS of rows, you need to map them to objects. Don't start talking about Gemstone, I like, it's rock solid, but sometimes, most of the times I would say, it's out of the discussion.
Even with objects mapped to tables, you can do real good object programming.
I don't want to see another isolated Smalltalk again, the more able you are to interconnect with the external world, the better.
This is not the case of Pharo. As you may know, most of the ESUG people are under the Pharo project. ESUG has selected SqueakDBX as a SummerTalk project and has sponsored us, not only in 2008 but again this year. See: http://www.esug.org/Promotion/SummerTalk So, you should notice that at least ESUG is interested in relational database access. Best, Mariano
Regards,
Esteban A. Maringolo
2009/8/16 Carlos Crosetti <carlos@mostar.com.ar>:
IMHO Pharo must stick to the roadmap milestones, keeping clear boundaries on what goes in and out - I value that some people are acting as gatekeepers.
Then a second community, those who develop frameworks that run on top of Pharo, like the authors of frameworks of Seaside, Glorp,,SqueakDBX (to name a few coming from the top of my head) may probably try to ensure their frameworks progresses aligned with the Pharo releases, demanding a rrobust and performant Smalltalk system impementattion.
Now, to boost Pharo adoption, beyod smalltalkers, and to capture the attention of new people, probably not familiar with the language, technology, style, the system itself, the paradigm, and (why not) the culture,, a new foundation of spin-off should address the level of effort to envision and manufacture... #1 a rich set of widgets and #2 recipes showing how to combine them to produce high-impact realtime client GUIs
As an example I mention what - Swing, AWT and SWT is for Java, - Tk is for Tcl, - GTK+ to C++, (and lots of....) - UIPaainter to VisualWorks,
and so on..:)
-----Mensaje original----- De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr]En nombre de csrabak@bol.com.br Enviado el: Sábado, 15 de Agosto de 2009 01:04 p.m. Para: Pharo-project@lists.gforge.inria.fr Asunto: Re: [Pharo-project] ORM for Pharo -- ½ OFF
Mariano,
I can understand the goal be Pharo idea and goal as you post. What I'm trying to bring (and hopefully add to this discussion) is how can we arrive there.
We need to narrow down the definition of "enterprise application" and see where Pharo can start to thrive. No all encompassing approach would work as notwithstanding how poweful and complete Pharo could become it will not be anytime soon.
The notion that Pharo be not assotiated per se to any UI it is a strong (and I vote to maintain it) design goal but in order to push forward Pharo together with robust and clean implementation we'll need a lot of energy and effort to produce enough educational materials like tutorial, manuals, etc., it will be confusing all the time have an example that do not work in another minor variation of UI (to stay in a single topic).
So I return to the point: we need to have more clear goals on what particular realm we see Pharo as feasible for enterprise development and be able to enumerate what are the advantages of Pharo versus the other approaches.
Hope it is more explicit now ;-)
Em 14/08/2009 20:42, Mariano Martinez Peck < marianopeck@gmail.com > escreveu:
2009/8/14 <csrabak@bol.com.br>
Mariano,
I agree (and I myself have been on the Research side getting answers similar to those ones) in fact I'll add another item to your list:
-- They have an "architectural steering committee" that dictates use of some RDBS
I've seen this even requiring some ERP used different database engine
thas
suggested by supplier. . .
So if we want to compete with enterprise applications we need to get into some Enterprise:
We're still thinkering with printing in Pharo (and this is PITA when attempting to be platform agnostic), so no Report Generator still, no matter how well you connect to a RDBS, any slightly above trivial example CRUD application will need this support.
Our present set of widgets is sleek but still not as comprehensive as the other competing approaches, and we still have not created enough baseline to have an "echo system" so third parties can augment them as it happens now with Java, .Net and happened (and still as legacy updates) in Delphi and VB.
So if the goal is to reach those enterprise trench we have to find some company that would profit of having [Pharo] Smalltalk as a primary language to customize or augment their system, as today (say as sake of example, SAP has ABAP but with Netweaver is going Java, and they competitors similar path).
Let's think about this: historically some (comercial) Smalltalks allowed via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things similar as VB (in fact even Tcl and Python allow that), but what is the "productivity" of programmer that finds a tutorial or an example in VB and has to "translate" it to Smalltalk?
As today can we enumerate what would be an advantage of doing something in Pharo instead of some "mainstream" language just to do some GUI painting CRUD application?
I don't know if I understand you. The idea and goal behind Pharo is to have the open, free, clean and robust smalltalk that we were missing for years for commercial applications. At least that's my idea of Pharo. It must be a platform and a base where you can create tools in it and with both of them create real applications.
In my opinion Pharo shouldn't be associated with a particular UI (web or desktop) neither to a persistence strategy. Pharo must be the base of all that. So then you can have differents alternatives: For UI's you can have PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But pharo is not coupled with any of them. You will then choose the solutions that best feets your needs.
In summary, I would love to use Pharo as platform to build enterprise and commercial applications. No matter how do I persist or display my objects.
Best,
Mariano
again my 0.01999....
Regards,
--
Cesar Rabak
Em 14/08/2009 16:57, Mariano Martinez Peck < marianopeck@gmail.com > escreveu:
2009/8/14 <csrabak@bol.com.br>
Esteban,
I'm comenting this on philosophical grounds.
I understand the efforts to have SqueakDBX and other ORM in Pharo are motivated by Seaside and other "production" initiatives so, again, my
food
for thought is more an intellectual contribution which I see as useful for Pharo as project:
I don't see Pharo any time soon® having all the toolset to be able to compete in the CRUD¹ realm with more streamlined tools and besides, not matter how much theoretical work has been done on ORM, the "impedance mismatch" is still there,
Hi! I am agree with you about the "impedance mismatch". I think that if I am free to choose a persistence strategy I would use an OODB. However, if we are talking about real enterprise application (not a simple webpage) being able to choose the persistence strategy is practically impossible. We did a survey last year and the results were that most of the times you cannot choose. Of course, the client has a lot of reasons:
- The client already has a RDBMS - They had paid for it and have the license (sometimes) - They want a company's support. The only company here is Gemstone. - RDBMS has history and it is an standard - They have knowledge about it - Interaction with other system (even legazy systems) - They are afraid of using another persistence strategy - They want to use SQL - They have DBAs - The persistence is difficult to negotiate
So. In my opinion, if Pharo wants to be used really as a platform for enterprise applications (competing to java, .NET, etc), it must have a good relational solution. Of course, when you are able to choose, you can go for another approach like OODB.
Best,
Mariano
a recent and practicall account of this (for Squeak) can be found in
http://onsmalltalk.com/simple-image-based-persistence-in-squeak
also, AIDA/Web has been able to run only storing thing in the image!
See
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba...
Since we'll increase the educational efforts to spread Pharo, I think that as technology we should to recover a bit of Smalltalk technology
and be
first more Object Oriented and then see if ORM still is so needed.
my 0.0199999....
--
Cesar Rabak
[1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete Em 14/08/2009 16:14, Esteban A. Maringolo < emaringolo@gmail.com > escreveu:
My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I have tables for most of it.
What are the choices I have for doing ORM in Pharo?
¿Does GLORP work? ¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express.
Best regards,
Esteban A. Maringolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Am 18.08.2009 um 17:23 schrieb Mariano Martinez Peck:
On Tue, Aug 18, 2009 at 10:37 AM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
This is not the case of Pharo. As you may know, most of the ESUG people are under the Pharo project. ESUG has selected SqueakDBX as a SummerTalk project and has sponsored us, not only in 2008 but again this year. See: http://www.esug.org/Promotion/SummerTalk
This page says "Welcome to SummerTalk 2008." Shouldn't it be 2009? Andreas
Yes, it should. Thanks On 8/18/09, Andreas Wacknitz <A.Wacknitz@gmx.de> wrote:
Am 18.08.2009 um 17:23 schrieb Mariano Martinez Peck:
On Tue, Aug 18, 2009 at 10:37 AM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
This is not the case of Pharo. As you may know, most of the ESUG people are under the Pharo project. ESUG has selected SqueakDBX as a SummerTalk project and has sponsored us, not only in 2008 but again this year. See: http://www.esug.org/Promotion/SummerTalk
This page says "Welcome to SummerTalk 2008." Shouldn't it be 2009?
Andreas
+1 On Aug 15, 2009, at 1:42 AM, Mariano Martinez Peck wrote:
2009/8/14 <csrabak@bol.com.br>
Mariano,
I agree (and I myself have been on the Research side getting answers similar to those ones) in fact I'll add another item to your list:
-- They have an "architectural steering committee" that dictates use of some RDBS
I've seen this even requiring some ERP used different database engine thas suggested by supplier. . .
So if we want to compete with enterprise applications we need to get into some Enterprise:
We're still thinkering with printing in Pharo (and this is PITA when attempting to be platform agnostic), so no Report Generator still, no matter how well you connect to a RDBS, any slightly above trivial example CRUD application will need this support.
Our present set of widgets is sleek but still not as comprehensive as the other competing approaches, and we still have not created enough baseline to have an "echo system" so third parties can augment them as it happens now with Java, .Net and happened (and still as legacy updates) in Delphi and VB.
So if the goal is to reach those enterprise trench we have to find some company that would profit of having [Pharo] Smalltalk as a primary language to customize or augment their system, as today (say as sake of example, SAP has ABAP but with Netweaver is going Java, and they competitors similar path).
Let's think about this: historically some (comercial) Smalltalks allowed via OLE (a.k.a. COM, etc.) to access Microsoft Office features and do things similar as VB (in fact even Tcl and Python allow that), but what is the "productivity" of programmer that finds a tutorial or an example in VB and has to "translate" it to Smalltalk?
As today can we enumerate what would be an advantage of doing something in Pharo instead of some "mainstream" language just to do some GUI painting CRUD application?
I don't know if I understand you. The idea and goal behind Pharo is to have the open, free, clean and robust smalltalk that we were missing for years for commercial applications. At least that's my idea of Pharo. It must be a platform and a base where you can create tools in it and with both of them create real applications.
In my opinion Pharo shouldn't be associated with a particular UI (web or desktop) neither to a persistence strategy. Pharo must be the base of all that. So then you can have differents alternatives: For UI's you can have PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But pharo is not coupled with any of them. You will then choose the solutions that best feets your needs.
In summary, I would love to use Pharo as platform to build enterprise and commercial applications. No matter how do I persist or display my objects.
Best,
Mariano
again my 0.01999....
Regards,
--
Cesar Rabak
Em 14/08/2009 16:57, Mariano Martinez Peck < marianopeck@gmail.com > escreveu:
2009/8/14 <csrabak@bol.com.br> Esteban,
I'm comenting this on philosophical grounds.
I understand the efforts to have SqueakDBX and other ORM in Pharo are motivated by Seaside and other "production" initiatives so, again, my food for thought is more an intellectual contribution which I see as useful for Pharo as project:
I don't see Pharo any time soon® having all the toolset to be able to compete in the CRUD¹ realm with more streamlined tools and besides, not matter how much theoretical work has been done on ORM, the "impedance mismatch" is still there,
Hi! I am agree with you about the "impedance mismatch". I think that if I am free to choose a persistence strategy I would use an OODB. However, if we are talking about real enterprise application (not a simple webpage) being able to choose the persistence strategy is practically impossible. We did a survey last year and the results were that most of the times you cannot choose. Of course, the client has a lot of reasons:
- The client already has a RDBMS - They had paid for it and have the license (sometimes) - They want a company's support. The only company here is Gemstone. - RDBMS has history and it is an standard - They have knowledge about it - Interaction with other system (even legazy systems) - They are afraid of using another persistence strategy - They want to use SQL - They have DBAs - The persistence is difficult to negotiate
So. In my opinion, if Pharo wants to be used really as a platform for enterprise applications (competing to java, .NET, etc), it must have a good relational solution. Of course, when you are able to choose, you can go for another approach like OODB.
Best,
Mariano a recent and practicall account of this (for Squeak) can be found in
http://onsmalltalk.com/simple-image-based-persistence-in-squeak
also, AIDA/Web has been able to run only storing thing in the image! See
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba...
Since we'll increase the educational efforts to spread Pharo, I think that as technology we should to recover a bit of Smalltalk technology and be first more Object Oriented and then see if ORM still is so needed.
my 0.0199999....
--
Cesar Rabak
[1] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete Em 14/08/2009 16:14, Esteban A. Maringolo < emaringolo@gmail.com > escreveu:
My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I have tables for most of it.
What are the choices I have for doing ORM in Pharo?
¿Does GLORP work? ¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express.
Best regards,
Esteban A. Maringolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The point is that pharoers should implement the vision not pharo. We have enough to do. The fact that pharo will succeed depends also on us as a community nor just 5 guys doing an integration of fixes. Stef
Stef,
I understand you agree with Mariano. Now how will Pharo fulfill this vision?
--
Cesar Rabak
PS.: See also my reply to Mariano
Em 16/08/2009 06:12, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu:
+1
On Aug 15, 2009, at 1:42 AM, Mariano Martinez Peck wrote:
2009/8/14
Mariano,
I agree (and I myself have been on the Research side getting answers similar to those ones) in fact I'll add another item to your list:
-- They have an "architectural steering committee" that dictates use of some RDBS
I've seen this even requiring some ERP used different database engine thas suggested by supplier. . .
So if we want to compete with enterprise applications we need to get into some Enterprise:
We're still thinkering with printing in Pharo (and this is PITA when attempting to be platform agnostic), so no Report Generator still, no matter how well you connect to a RDBS, any slightly above trivial example CRUD application will need this support.
Our present set of widgets is sleek but still not as comprehensive as the other competing approaches, and we still have not created enough baseline to have an "echo system" so third parties can augment them as it happens now with Java, .Net and happened (and still as legacy updates) in Delphi and VB.
So if the goal is to reach those enterprise trench we have to find some company that would profit of having [Pharo] Smalltalk as a primary language to customize or augment their system, as today (say as sake of example, SAP has ABAP but with Netweaver is going Java, and they competitors similar path).
Let's think about this: historically some (comercial) Smalltalks allowed via OLE (a.k.a. COM, etc.) to ac cess Microsoft Office features and do things similar as VB (in fact even Tcl and Python allow that), but what is the "productivity" of programmer that finds a tutorial or an example in VB and has to "translate" it to
Smalltalk?
As today can we enumerate what would be an advantage of doing something in Pharo instead of some "mainstream" language just to do some GUI painting CRUD application?
I don't know if I understand you. The idea and goal behind Pharo is to have the open, free, clean and robust smalltalk that we were missing for years for commercial applications. At least that's my idea of Pharo. It must be a platform and a base where you can create tools in it and with both of them create real applications.
In my opinion Pharo shouldn't be associated with a particular UI (web or desktop) neithe r to a persistence strategy. Pharo must be the base of all that. So then you can have differents alternatives: For UI's you can have PolyMorph and the UI Builder. For Web you can have Seaside and Aida/Web. But pharo is not coupled with any of them. You will then choose the solutions that best feets your needs.
In summary, I would love to use Pharo as platform to build enterprise and commercial applications. No matter how do I persist or display my objects.
Best,
Mariano
again my 0.01999....
Regards,
--
Cesar Rabak
Em 14/08/2009 16:57, Mariano Martinez Peck < marianopeck@gmail.com > escreveu:
2009/8/14 Esteban,
I'm comenting this on philosophical grounds.
I understand the efforts to have SqueakDBX and other ORM in Pharo are motivated by Seaside and other "production" initiatives so, again, my food for thought is more an intellectual contribution which I see as useful for Pharo as project:
I don't see Pharo any time soon® having all the toolset to be able to compete in the CRUD¹ realm with more streamlined tools and besides, not matter how much theoretical work has been done on ORM, the "impedance mismatch" is still there,
Hi! I am agree with you about the "impedance mismatch". I think that if I am free to choose a persistence strategy I would use an OODB. However, if we are talking about real enterprise application (not a simple webpage) being able to choose the persistence strategy is practically impos sible. We did a survey last year and the results were that most of the times you cannot choose. Of course, the client has a lot of reasons:
- The client already has a RDBMS - They had paid for it and have the license (sometimes) - They want a company's support. The only company here is Gemstone. - RDBMS has history and it is an standard - They have knowledge about it - Interaction with other system (even legazy systems) - They are afraid of using another persistence strategy - They want to use SQL - They have DBAs - The persistence is difficult to negotiate
So. In my opinion, if Pharo wants to be used really as a platform for enterprise applications (competing to java, .NET, etc), it must have a good relational solution. Of course, when you are able to choose, you can go for another appro ach like OODB.
Best,
Mariano a recent and practicall account of this (for Squeak) can be found in
http://onsmalltalk.com/simple-image-based-persistence-in-squeak
also, AIDA/Web has been able to run only storing thing in the image! See
http://groups.google.com/group/comp.lang.smalltalk/browse_thread/thread/d3ba...
Since we'll increase the educational efforts to spread Pharo, I think that as technology we should to recover a bit of Smalltalk technology and be first more Object Oriented and then see if ORM still is so needed.
my 0.0199999....
--
Cesar Rabak
[1] http://en.wikipedia.org/w iki/Create,_read,_update_and_delete Em 14/08/2009 16:14, Esteban A. Maringolo < emaringolo@gmail.com > escreveu:
My prototype is getting less proto, and I found out it doesn't have complex relations, and the system is going to perform faster if I
have
tables for most of it.
What are the choices I have for doing ORM in Pharo?
¿Does GLORP work? ¿Any other options? I don't have a strong preference for the RDBMS engine, it can be anything (free), being it MySQL, PostgreSQL or Sql Server Express.
Best regards,
Esteban A. Maringolo
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
__________________ _____________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote:
The point is that pharoers should implement the vision not pharo. We have enough to do. The fact that pharo will succeed depends also on us as a community nor just 5 guys doing an integration of fixes.
Stef
Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Typ... Part of this is the *purge* of the string Squeak from the image, so Quit Squeak Vm doesn't fire the quit logic (a) I'd rather not have to build two VMs, one for Squeak and one for Pharo (b) Also I'd rather not have to answer is the Pharo VM different from the Squeak VM? (c) If you take the Squeak.app and rename it all to Pharo then someone has to manage that process and ensure the Pharo clone is cloned properly from the Squeak.app (d) if you have a Pharo.app the question then is where did it come from? (e) I do agree having a Pharo app, then seeing quit Squeak VM is very confusing, therefore people should be able to change that to suit their needs. So how would people like to see how this would work. This of course precludes any discussion of how the linux & windows versions behave and give textual feedback. -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Why are the menus not being built from within the image/and/or the path/name of the executable? On Aug 16, 2009, at 5:25 PM, John M McIntosh wrote:
On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote:
The point is that pharoers should implement the vision not pharo. We have enough to do. The fact that pharo will succeed depends also on us as a community nor just 5 guys doing an integration of fixes.
Stef
Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Typ...
Part of this is the *purge* of the string Squeak from the image, so Quit Squeak Vm doesn't fire the quit logic
(a) I'd rather not have to build two VMs, one for Squeak and one for Pharo (b) Also I'd rather not have to answer is the Pharo VM different from the Squeak VM? (c) If you take the Squeak.app and rename it all to Pharo then someone has to manage that process and ensure the Pharo clone is cloned properly from the Squeak.app (d) if you have a Pharo.app the question then is where did it come from? (e) I do agree having a Pharo app, then seeing quit Squeak VM is very confusing, therefore people should be able to change that to suit their needs.
So how would people like to see how this would work.
This of course precludes any discussion of how the linux & windows versions behave and give textual feedback.
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The simplest for you and On Aug 17, 2009, at 2:25 AM, John M McIntosh wrote:
On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote:
The point is that pharoers should implement the vision not pharo. We have enough to do. The fact that pharo will succeed depends also on us as a community nor just 5 guys doing an integration of fixes.
Stef
Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Typ...
Part of this is the *purge* of the string Squeak from the image, so Quit Squeak Vm doesn't fire the quit logic
(a) I'd rather not have to build two VMs, one for Squeak and one for Pharo
agree. Now does the event cleaning and other have no impact on the vm level?
(b) Also I'd rather not have to answer is the Pharo VM different from the Squeak VM? agree
(c) If you take the Squeak.app and rename it all to Pharo then someone has to manage that process and ensure the Pharo clone is cloned properly from the Squeak.app
yes may be we could have a script for that
(d) if you have a Pharo.app the question then is where did it come from?
**We** could have a script for transforming squeakvm into pharo vm
(e) I do agree having a Pharo app, then seeing quit Squeak VM is very confusing, therefore people should be able to change that to suit their needs.
may be we should use platform and extend it to vm or system name
So how would people like to see how this would work.
This of course precludes any discussion of how the linux & windows versions behave and give textual feedback.
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I think that the name has to come from the executable. The idea of Pharo is to have a Smalltalk that can be shipped. So if someone were to create an application and wanted a custom wrapped double clickable file with a name like - oh - Sophie.app - then it would adjust the menus appropriately. On Aug 16, 2009, at 11:37 PM, Stéphane Ducasse wrote:
The simplest for you and
On Aug 17, 2009, at 2:25 AM, John M McIntosh wrote:
On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote:
The point is that pharoers should implement the vision not pharo. We have enough to do. The fact that pharo will succeed depends also on us as a community nor just 5 guys doing an integration of fixes.
Stef
Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Typ...
Part of this is the *purge* of the string Squeak from the image, so Quit Squeak Vm doesn't fire the quit logic
(a) I'd rather not have to build two VMs, one for Squeak and one for Pharo
agree. Now does the event cleaning and other have no impact on the vm level?
(b) Also I'd rather not have to answer is the Pharo VM different from the Squeak VM? agree
(c) If you take the Squeak.app and rename it all to Pharo then someone has to manage that process and ensure the Pharo clone is cloned properly from the Squeak.app
yes may be we could have a script for that
(d) if you have a Pharo.app the question then is where did it come from?
**We** could have a script for transforming squeakvm into pharo vm
(e) I do agree having a Pharo app, then seeing quit Squeak VM is very confusing, therefore people should be able to change that to suit their needs.
may be we should use platform and extend it to vm or system name
So how would people like to see how this would work.
This of course precludes any discussion of how the linux & windows versions behave and give textual feedback.
-- = = = = = = ===================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = = =====================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hello, I cleaned the menues, and moved things into the first menu that normally are there for all other Mac apps. For example all the Quit entries, "About" and "Preferences". Now, all these are not about "Squeak VM", but about "Pharo". So I checked a bit to see how Sophie had a nice Sophie menu, and I found that changing the info.plist would change the menu. I than stopped. So now we need to think about what to do. Do we want a "Squeak VM" menu with a "Preferences" entry that than is not about "Squeak VM"? I don't think so... Marcus On 16.08.2009, at 20:25, John M McIntosh wrote:
On 16-Aug-09, at 2:50 PM, Stéphane Ducasse wrote:
The point is that pharoers should implement the vision not pharo. We have enough to do. The fact that pharo will succeed depends also on us as a community nor just 5 guys doing an integration of fixes.
Stef
Ok let's talk about bug http://code.google.com/p/pharo/issues/detail?id=1068&q=quit&colspec=ID%20Typ...
Part of this is the *purge* of the string Squeak from the image, so Quit Squeak Vm doesn't fire the quit logic
(a) I'd rather not have to build two VMs, one for Squeak and one for Pharo (b) Also I'd rather not have to answer is the Pharo VM different from the Squeak VM? (c) If you take the Squeak.app and rename it all to Pharo then someone has to manage that process and ensure the Pharo clone is cloned properly from the Squeak.app (d) if you have a Pharo.app the question then is where did it come from? (e) I do agree having a Pharo app, then seeing quit Squeak VM is very confusing, therefore people should be able to change that to suit their needs.
So how would people like to see how this would work.
This of course precludes any discussion of how the linux & windows versions behave and give textual feedback.
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (9)
-
Andreas Wacknitz -
Carlos Crosetti -
csrabak＠bol.com.br -
Eagle Offshore -
Esteban A. Maringolo -
John M McIntosh -
Marcus Denker -
Mariano Martinez Peck -
Stéphane Ducasse